From ???@??? Fri Jan 13 12:55:01 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA19266 for ; Fri, 13 Jan 1995 12:48:17 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rSq8j-000fIvC; Fri, 13 Jan 95 09:50 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA04125; Fri, 13 Jan 95 09:49:37 PST Date: Fri, 13 Jan 1995 09:49:37 -0800 (PST) From: Gregory Glen Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Re: pheno-geno species confusion In-Reply-To: <9501131546.AA17553@altair.krl.caltech.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think that the actual implementation of pheno and geno stuff should belong in the alife group...but your comments bring up a big source of the confusion. The Universe (non-alifers) term 'species' as being merely a 'batch' of alien offspring. So thus if the average 'batch' of offspring is about 10 aliens, then each species would be about 10 aliens. batch=species for the Universians. It is merely a term to describe a part of the data structure which holds the pictures for one batch of aliens as well as a few un-diverse things (like armour, all aliens of a certain batch will have the same initial armour value. Other examples are MASS, THRUST, TURNING THRUST, WEAPONS...physical things), there will also could be a section of behaviour code in there to direct species group actions (each species would have the index for it's parent's specii, thus linking the various species, for possible 'cousin'-esque group behaviours). Aside from those things that will be similar to a whole batch of alien offspring, the rest of the alien data will be stored in the alien structure itself, which wach alien has one of. It seems the Alifers have a different idea for what the term 'species' means. The Universians would have about 100 species in a 1000 alien soup (about 10 per species, average), where the Alifers would have 3, perhaps 4?? Obviously we're mixing up terms here. Martijn, as part of that file your writing, could you please include a glossary of terms...we throw a lot of terminology around and having definitions of those terms would make things easier... That's all for now. The groups are going to be re-forming soon (most people are coming back to school), so I'm preparing some planz..so when they all come back, we'll be on the starting line...ready to run! One lingering thing is the universe.h A major portion of what is yet-to-be decided is the alien data structures! So Charles and Martijn, please discuss with your groups on how you want to store your data, and what access you want to other things etc... I'd like to get that universe.h finished and official soon...so we can start coding. Enough. Talk to yall later -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Fri Jan 13 14:46:17 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA01607 for ; Fri, 13 Jan 1995 14:07:19 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rSrMb-000fIvC; Fri, 13 Jan 95 11:08 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id UAA22398 for ; Fri, 13 Jan 1995 20:06:37 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id UAA04349 for ag-directors@alnilam.krl.caltech.edu; Fri, 13 Jan 1995 20:06:34 +0100 From: Martijn Faassen Message-Id: <199501131906.UAA04349@laurel.stud.phil.ruu.nl> Subject: Re: pheno-geno species confusion To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Fri, 13 Jan 1995 20:06:33 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4154 Hello again, First a tiny list of some terminology (though note that in my previous text when I wrote 'species' I tried to refer to something hard-wired that I feared some others were thinking about, not the concept I'll try to describe now): Tiny Alife Terminology List Genotype: Everything that can be inherited by offspring of the creature. Genotype can be (but doesn't have to be) expressed in the phenotype of the creature. Genotype is not visible from the outside, except through phenotype, or if you actually can look at the genetic code. In biological creatures the genotype is (roughly) represented in its DNA. In the aliens, the genotype will consist of several parts: - Body traits: This is a description of the investment pattern of the alien in things like thrust power, types of weapons, shields, etc. - Behaviour program: This is a program written in a 'virtual machine code'. Phenotype: What the creature looks like, its behaviour. The phenotype of a creature is the expression of its genotype (though not all of the genotype does have to express itself. You can have brown eyes and still have the recessive gene for blue eyes, which might be expressed in the phenotype of your offspring). Phenotype can be viewed as the thing that happens when you 'execute' the genetic code of a creature (which after all determines embryonic growth, growth of the brain, etc, etc). In biological creatures the phenotype is what you see when you observe or examine a creature. In the aliens, the phenotype will consists of several parts: - Body traits: This is the result of the alien's investment pattern. If the egg of the alien had much to invest (was a healthy egg), the resulting body traits will be somewhat better than those of weaker eggs. - Behaviour: The behaviour program is executed, and as a result of the interaction with the environment, certain behaviour emerges. - Picture of the alien: This is based on mostly what body traits the alien has, but perhaps also somewhat on the behaviour program, if we want. It is of course also possible to completely disconnect the picture from body traits and behaviour program, in which case we need 'picture genotype' too. Species: This is not something explicitly present, but a concept we humans apply to creatures, to classify them. Often the concept of species has been tried to make more formal by saying something is in the same species if, upon mating, viable offspring is the result. Of course this would exclude all nonsexual creatures, like bacteria. And, sometimes two creatures which we would like to see as seperate species actually produce offspring (bunny and hare, even lion and tiger!). Members of the same species aren't all exact genetic clones, they can differ in a lot of ways (look at humans for an example). In the aliens, a species would be something that the player would identify as being a species ("all the fast moving red ones"). It is plausible that something that the player identifies as one species has a very similar geno- type in all its members, though it's not strictly necessary (in nature, obverse some forms of extreme mimicry). In practice, we can however assume that this is the case, for memory considerations. Therefore, if we assume the picture phenotype of an alien is based on (some features of) the genotype of the creature, we can write a picture generating function which has as input those features of the genotype. For similar genotypes, those features will generally be similar, so we might only have to generate one single stock picture for each cluster of similar genotypes, i.e, for each species. This way we can hopefully limit the amount of memory needed. Actually, thinking about this..the more memory is available, the smaller we can set the range in which still the same picture is used. Also, if the number of species happens to increase, we can simply increase the range, so we only have to use roughly the same amounts of pictures! Okay, I seem to have wandered away a bit from my terminlogy explanation, but I hope I gave you all some useful ideas to consider. Have a nice weekend! Martijn From ???@??? Sun Jan 08 10:34:03 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id UAA15864 for ; Fri, 6 Jan 1995 20:22:57 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rQPuI-000fIvC; Fri, 6 Jan 95 17:25 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id CAA19917 for ; Sat, 7 Jan 1995 02:23:19 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id CAA12044 for ag-directors@alnilam.krl.caltech.edu; Sat, 7 Jan 1995 02:23:14 +0100 From: Martijn Faassen Message-Id: <199501070123.CAA12044@laurel.stud.phil.ruu.nl> Subject: Comments to universe.h To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Sat, 7 Jan 1995 02:23:13 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 12387 Hi everybody, I'm back! Happy new year! Here's some comments coming from the alife perspective on universe.h: > typedef struct { > short keys; // flip bits to indicate actions (1==YES, bit 0 = LSB) > // bit 0 = am I turning left, bit 1 = am I turning right, > // bit 2 = am I thrusting forwards, bit 3 = am I thrusting backwards > // bit 4 = am I breeding, bit 5 = am I eating > // bit 6 = am I picking something up, bit 7 = am I firing > short time; // for aliens; represents syskeys for player. > // for aliens: bits 1,0 = how long am I turning This means an alien can only turn for a maximum of 3 time? Not much use for this then, I suppose? > // bits 3,2 = how long am I thrusting > // bits 5,4 = how many shots do I want to fire Same comment for this; I don't know if we actually need this. (and throwing this out we make the aliens more equal to the player..) > // bits 7,6 = which weapon am I firing Doesn't the player need something like this too? (assuming the player can also cycle through weapons?). I propose one, or maybe two, 'cycle' virtual keys. The player presses the key and cycles back to the next (and with 2 keys, cycles back with the other key) weapon. Same for alien. 4 weapons per alien sounds fine to me, though others may have other opinions? (with the cycle keys it's easier to put in more weapons) > // for player: bit 0 = quit, bit 1 = pause (go to main menu) > // bit 2 = toggle sound, bits 3,4,5 = ? (what other syskeys do we want?) If we go for my approach, which is a way to 'select' objects surrounding you, cycling through them with two keys, we need another two keys. Selection would be a very handy feature to have in the game; you can select a target for a targetting weapon, select precisely what to pick up, or eat, or mate with. Or to scan. We need this cycling feature (in a slightly different form anyway, for the alife part, because the alife needs to be able to example some properties (is it an egg? moving where? alien? bullet?) of the objects flying around it. So, I suggest we add the cycling feature. :) > // bits 7,6 = which weapon am I firing Why a double set of this? I'm not clear on the distinction made between the alien and the player here... > } actions; // never modified for inactive objects like asteroids Agreed there, about the never modified. Nice unifying approach for objects. Now..species.. If we want to get evolution going, we need a diverse population of aliens. This means aliens should ideally all differ a tiny bit from each other, in behaviour, in looks, in weapons. Just like any biological creature (like humans) differs slightly from the others in that species. Eventually species might drift apart, some aliens might evolve in different directions than the others, and new species can form. This however, is rather impossible to hardcode in. So, instead of a rather useless proliferation of species, I hopefully present my ideas on species slightly coherently, below. > // SPECIESTYPE - A species of object. > typedef struct spec { > // FE stuff. > void *pict[MAXPIC][MAXROT]; // the pictures for that species... > > unsigned short thrust, turn; // the increment by which the object > // will change its velocity or facing when thrusting or turning > unsigned short maxlife, mass; // maximum life and mass for collisions > // note that "mass" for projectiles is the amount of damage they do > // and for food sources it is the amount of life they give to the eater > // (life counter for food sources can be used to eliminate them if they are > // not eaten within a certain interval...they'll gradually lose life Perhaps it would be simpler to split mass and the two other concepts, destructive damage and nutriceous value for food, into different variables as well. This way we have more ways to vary this, and it's less confusing. (we might want a light but destructive projectile, or a heavy but rather unnourishing hunk of food - perhaps asteroids are this, and shipwrecks are lighter, but much more nourishing) > spec *weap[4]; // pointers to the "species" each weapon belongs to We might want a put in a linked list with weapons instead, so we can abritrarily vary the amount of weapons. (though I wouldn't object if we don't do this, 4 weapons seems reasonable too) Note on the use of 'species' here, I don't think we need different species for weapons, perhaps we'd do better to have a single weapon species , with different weapon types ('objects'), in it. If two ships use the same type of weapon, they simply can both refer to the same object, to see what the weapon does, and what kinds of projectiles it produces, etc. > // what other traits do we want? > > // behaviour stuff...Alife will fill in. > } speciestype; > > speciestype species[MAXSPECIES]; > > // species 0 = player, then there are inanimate things, then food sources, > // then eggs, then projectiles, then aliens, then boss aliens. > > typedef struct { > unsigned short specnum;// the species index of object. > > unsigned short x, y; // 0..65536 mapsize max. > // X = x/1024 , Y = y/1024 , current sectors = (X,Y),(X-1,Y),(X,Y-1),(X-1,Y-1) > > char frame; // current frame of animation. > > short velx, vely; // the velocity along the x and y axies. > > unsigned char facing; // the direction (0-255) that the obj is facing > > short life; // the amount of life the object has left I'm wondering; is this equal to the amount of energy the object has left? I should dig up the old energy summary text I did somewhere, for this. > > object *gnext, *gprev; // global next/previous pointers. > object *lnext[4], *lprev[4];// local next/prev pointers, accessed via > // hash function. > > actions action; // what the object's move is > // should we have the contents of actions inline here once we finalize them? > } object; > > object sector[64][64],objects[MAXOBJECTS]; // sector and global object lists > //--Alife-------------------------------------------------------------------- > /***************************************************************************\ > * AI_AlienMove - Perform an alien's move. * > * Author - * > \***************************************************************************/ > short AI_AlienMove ( // RETURN: Virtual keypresses (bitwise). > short index // INPUT : Index number of Alien. > // Aliens don't have index numbers...maybe a pointer to the alien, which > // AI_AlienMove could use to access its behavior, as well as to determine > // which sectors were nearby and look at the relevant (global) sector lists? Agreed, go for a pointer here. > ); > > /***************************************************************************\ > * AI_CreateHybrid - Create a new alien. * > * Author - * > \***************************************************************************/ > Object AI_CreateHybrid ( // RETURN: Hybrid alien. > short *species, // OUTPUT: New species number. New species number? I'd prefer to view the aliens as one species. (so only one species number) Subspecies might *evolve*, but we don't need to hardwire in species, see my earlier comments on species. > Object parent1, // INPUT : Parent #1 > Object parent2 // INPUT : Parent #2 > ); > > //--Art/Sound---------------------------------------------------------------- > /***************************************************************************\ > * AS_MorphSpecies - Morph a new alien species. * > * Author - * > \***************************************************************************/ > void AS_MorphSpecies ( // RETURN: None. > short species, // INPUT : New morph species number. > short parent1, // INPUT : Species number of parent 1. > short parent2 // INPUT : Species number of parent 2. > ); Again I object to the use of species in this context. I propose we do the following instead: Each alien has with it a 'relatedness number' or maybe 2 numbers, or more. This relatedness number is determined by some alife routine (perhaps based on ancestry, or based on similarity, but Universe doesn't need to worry about that). The relatedness number is used by MorphAlien (as opposed to morph species) as an input. We don't need to input the parents, that's done by an alife routine earlier. So, what I'd like to see is a MorphAlien routine, which produces a picture of an alien, and the closer the relatedness number of one input is to the relatedness number of another input, the closer the two aliens resemble. If two relatedness numbers come very close, the aliens look exactly the same (this is to so we don't need too much memory, the higher we make this 'look the same with different relatedness numbers', the less memory we'd need). If one relatedness number is too simplistic, well, we have a lot of other genetic info we might use for this: power of thrusting, speed of turning, which weapons, perhaps colors too. So, basically I'd like a function, which builds a picture of the alien based on it's genetic code. If a single number (a relatedness number) or a simple set of numbers is the simplest solution for MorphAlien, alife can have a function to produce these numbers out of the genetic info. If however people think they need more detailed info, no problem, both Universe and Alife have more than enough information to supply the morphing routines with. > #define MAXSPECIES 20 // # of species on field at once. Why so low a number? Again, I'd prefer something like MAXOBJECTS instead, why put a top on the amount of species (or different aliens, as I'd prefer). > #define MINFOOD 2 > #define MAXFOOD 4 // range of species numbers allocated for food > // sources (this includes eggs, whose species number will be MAXFOOD) > #define MINAI 5 // lowest species number of something that uses AI > // (projectiles and aliens) > #define MINALIEN 10 // lowest alien's species number Again, I suggest we alter the species concept into something like this: One species is the player. One species is all projectile objects (consisting of code, and other attributes).. One species is all kinds of food objects. One species is asteroids, or other inanimate objects. One species is all the aliens objects. Each object in a particular species shares certain common properties, but also most objects in a species also have differences. (especially the aliens species). If two objects are exactly the same except for coordinates, and energy, and life, and perhaps things like alife intruction pointer, we might consider giving them shared alife code, and all the rest, which would amount to the concept of species as I see it used currently. But, this isn't too likely to happen. Yes, my approach will be heavy on memory. :) > #define MAXROT 16 // # of rotations of the pictures, some systems w/ > // lots of memory could do 32 or even 64! > #define MAXOBJECTS 100 // # of objects in field at once. > Anyway, I probably am confusing about all this, so if people want it (mail me if so) I'll prepare a plaintext description of what I mean. I might do this anyway. I hope my comments aren't taken too heavily, the bulk of this all is fine, but the species (I mean that we *don't* hard code them in) thing is, I think, really important from an alife point of view. And we do want those evolving aliens. Note that this doesn't mean we can't *perceive* species. If we see big red fast nasty ships evolve that turn in circles around you and all use little pink missiles, we might call those a species, and the small yellow slow ones that reproduce madly, another one. But the code doesn't know that. (we can have somekind of way to enable the player to name the species, though, if we'd like, but species isn't in the code) Thanks for listening to my comments, and any comments on them are of course always welcome! Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Sun Jan 08 10:34:04 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id AAA01215 for ; Sat, 7 Jan 1995 00:38:21 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rQSCR-000fIvC; Fri, 6 Jan 95 19:52 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id TAA23148 for ag-directors@alnilam.krl.caltech.edu; Fri, 6 Jan 1995 19:50:21 -0800 From: Adrian Tymes Message-Id: <199501070350.TAA23148@mcl.mcl.ucsb.edu> Subject: Comments to universe.h (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Fri, 6 Jan 1995 19:50:20 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 12182 > > typedef struct { > > short keys; // flip bits to indicate actions (1==YES, bit 0 = LSB) > > // bit 0 = am I turning left, bit 1 = am I turning right, > > // bit 2 = am I thrusting forwards, bit 3 = am I thrusting backwards > > // bit 4 = am I breeding, bit 5 = am I eating > > // bit 6 = am I picking something up, bit 7 = am I firing > > short time; // for aliens; represents syskeys for player. > > // for aliens: bits 1,0 = how long am I turning > > This means an alien can only turn for a maximum of 3 time? Not much use > for this then, I suppose? Well, if we make time 16 bits then we can add more bits to the "how long will I do X" sections... > > // bits 7,6 = which weapon am I firing > > Doesn't the player need something like this too? (assuming the player > can also cycle through weapons?). I propose one, or maybe two, 'cycle' > virtual keys. The player presses the key and cycles back to the next > (and with 2 keys, cycles back with the other key) weapon. Same for > alien. 4 weapons per alien sounds fine to me, though others may have > other opinions? (with the cycle keys it's easier to put in more weapons) Note: the above defs are for the *aliens'* "time" variable. The defs below are for the *player's* "time" variable. Same variable name, different meaning (except that bits 6 and 7 denote the current weapon for both). > > // for player: bit 0 = quit, bit 1 = pause (go to main menu) > > // bit 2 = toggle sound, bits 3,4,5 = ? (what other syskeys do we want?) > > If we go for my approach, which is a way to 'select' objects surrounding > you, cycling through them with two keys, we need another two keys. Selection > would be a very handy feature to have in the game; you can select a target > for a targetting weapon, select precisely what to pick up, or eat, or mate > with. Or to scan. We need this cycling feature (in a slightly different form > anyway, for the alife part, because the alife needs to be able to example > some properties (is it an egg? moving where? alien? bullet?) of the objects > flying around it. So, I suggest we add the cycling feature. :) Maybe we should have a pointer to "current target" as part of the actions, then? Although it might be better as part of the object data itself... > > // bits 7,6 = which weapon am I firing > > } actions; // never modified for inactive objects like asteroids > > Agreed there, about the never modified. Nice unifying approach for objects. > > Now..species.. > > If we want to get evolution going, we need a diverse population of aliens. > This means aliens should ideally all differ a tiny bit from each other, > in behaviour, in looks, in weapons. Just like any biological creature > (like humans) differs slightly from the others in that species. > Eventually species might drift apart, some aliens might evolve in different > directions than the others, and new species can form. This however, is > rather impossible to hardcode in. > > So, instead of a rather useless proliferation of species, I hopefully > present my ideas on species slightly coherently, below. > > > // SPECIESTYPE - A species of object. > > typedef struct spec { > > // FE stuff. > > void *pict[MAXPIC][MAXROT]; // the pictures for that species... > > > > unsigned short thrust, turn; // the increment by which the object > > // will change its velocity or facing when thrusting or turning > > unsigned short maxlife, mass; // maximum life and mass for collisions > > // note that "mass" for projectiles is the amount of damage they do > > // and for food sources it is the amount of life they give to the eater > > // (life counter for food sources can be used to eliminate them if they are > > // not eaten within a certain interval...they'll gradually lose life > > Perhaps it would be simpler to split mass and the two other concepts, > destructive damage and nutriceous value for food, into different variables > as well. This way we have more ways to vary this, and it's less confusing. > (we might want a light but destructive projectile, or a heavy but rather > unnourishing hunk of food - perhaps asteroids are this, and shipwrecks are > lighter, but much more nourishing) Maybe...but remember that everything that we add to speciestype will be multiplied many times, and increase the total memory required...and this "value" would only be useful for projectiles and food (unless someone can think of an extra value that it might be useful to keep track of that would only apply to aliens and players, and would be species-wide...) > > spec *weap[4]; // pointers to the "species" each weapon belongs to > > We might want a put in a linked list with weapons instead, so we can > abritrarily vary the amount of weapons. (though I wouldn't object if we > don't do this, 4 weapons seems reasonable too) Maybe the weapons' species numbers could be in the linked list...the species themselves don't have "next" pointers, and can't (otherwise every species which could fire weapon A could fire weapon A -> next). Or maybe we could have an array of the species numbers of the weapons...which, when used by the weapons themselves, would refer to damage characteristics and/or submunitions (and food value for food sources). > Note on the use of 'species' here, I don't think we need different > species for weapons, perhaps we'd do better to have a single weapon species > , with different weapon types ('objects'), in it. If two ships use the > same type of weapon, they simply can both refer to the same object, to > see what the weapon does, and what kinds of projectiles it produces, etc. No...all the data that a weapon would use is already in speciestype, and "objects" refer to the projectile itself, rather than the projectile's type (unless we want a seperate data structure for weapons, but that would add complexity to all of the sections). > > // what other traits do we want? > > > > // behaviour stuff...Alife will fill in. > > } speciestype; > > > > typedef struct { [snip] > > short life; // the amount of life the object has left > > I'm wondering; is this equal to the amount of energy the object has left? Yes. If we want to keep track of fuel (for weapons/thrust/etc.), we can add that, although I don't think we should limit the aliens like this... [snip] > > /***************************************************************************\ > > * AI_CreateHybrid - Create a new alien. * > > * Author - * > > \***************************************************************************/ > > Object AI_CreateHybrid ( // RETURN: Hybrid alien. > > short *species, // OUTPUT: New species number. > > New species number? I'd prefer to view the aliens as one species. (so > only one species number) Subspecies might *evolve*, but we don't need > to hardwire in species, see my earlier comments on species. This function is supposed to create a new *species*. All of the aliens taken together are most definitely not the same species! > > Object parent1, // INPUT : Parent #1 > > Object parent2 // INPUT : Parent #2 > > ); > > > > //--Art/Sound---------------------------------------------------------------- > > /***************************************************************************\ > > * AS_MorphSpecies - Morph a new alien species. * > > * Author - * > > \***************************************************************************/ > > void AS_MorphSpecies ( // RETURN: None. > > short species, // INPUT : New morph species number. > > short parent1, // INPUT : Species number of parent 1. > > short parent2 // INPUT : Species number of parent 2. > > ); > > Again I object to the use of species in this context. I propose we do > the following instead: > > Each alien has with it a 'relatedness number' or maybe 2 numbers, or more. > This relatedness number is determined by some alife routine (perhaps based > on ancestry, or based on similarity, but Universe doesn't need to worry > about that). The relatedness number is used by MorphAlien (as opposed to > morph species) as an input. We don't need to input the parents, that's done > by an alife routine earlier. So, what I'd like to see is a MorphAlien > routine, which produces a picture of an alien, and the closer the relatedness > number of one input is to the relatedness number of another input, the closer > the two aliens resemble. If two relatedness numbers come very close, the > aliens look exactly the same (this is to so we don't need too much memory, > the higher we make this 'look the same with different relatedness numbers', > the less memory we'd need). If one relatedness number is too simplistic, > well, we have a lot of other genetic info we might use for this: power of > thrusting, speed of turning, which weapons, perhaps colors too. #1: Again, we are creating a new species, *NOT* an individual new alien with this routine. #2: How would we generate the new relatedness number? Since this routine will probably only be called by AI_GenerateHybrid, it could just pass the needed parameter (0 = identical to parent 1, 1 = identical to parent 2, between 0 and 1 = how much of parent 2 to put in (1-this = how much of parent 1 to put in)) directly. > > #define MAXSPECIES 20 // # of species on field at once. > > Why so low a number? Again, I'd prefer something like MAXOBJECTS instead, > why put a top on the amount of species (or different aliens, as I'd prefer). This is just until we see what memory constraints we have to work under... these numbers almost definitely will be changed. > > #define MINFOOD 2 > > #define MAXFOOD 4 // range of species numbers allocated for food > > // sources (this includes eggs, whose species number will be MAXFOOD) > > #define MINAI 5 // lowest species number of something that uses AI > > // (projectiles and aliens) > > #define MINALIEN 10 // lowest alien's species number > Again, I suggest we alter the species concept into something like this: > > One species is the player. Species #1 is the player. > One species is all projectile objects (consisting of code, and other > attributes).. How would we differentiate a dumb projectile from a seeking projectile? Which species a projectile is determies what its AI routine will be. > One species is all kinds of food objects. Maybe...if we made the food value as part of the object itself. > One species is asteroids, or other inanimate objects. Sure, if they all have the same picture, the same mass, etc. If we just do asteroids, then we can do this, but walls and nest objects will (at the least) have different pictures. > One species is all the aliens objects. *NOT*! Then all the aliens would have the same AI, the same mass, the same weapons, the same acceleration and turning speed, and no new alien species could be created. > Each object in a particular species shares certain common properties, > but also most objects in a species also have differences. (especially > the aliens species). Yes. Everything that is common among a species is stored in species, everything that is different is stored in the object. > If two objects are exactly the same except for coordinates, and energy, > and life, and perhaps things like alife intruction pointer, we might > consider giving them shared alife code, and all the rest, which would > amount to the concept of species as I see it used currently. But, this > isn't too likely to happen. Even if we define that as the way it happens in this program? > Yes, my approach will be heavy on memory. :) It is doable, but I'd rather save on memory so the player can fight more aliens. Plus, under the current approach, we can tally up the performance of every member of a species to see how well that species does, and have insurance against events like a super-killer-alien being born right into the path of a megabomb before it gets a shot off. From ???@??? Thu Jan 26 16:59:04 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id QAA15297 for ; Thu, 26 Jan 1995 16:46:37 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rXc4M-000fIvC; Thu, 26 Jan 95 13:49 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #8) id m0rXc1O-0004V9C; Thu, 26 Jan 95 23:46 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA03452; 26 Jan 95 20:52:55 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 26 Jan 95 11:28:01 +0200 Subject: Musicians Message-ID: <11a_9501262052@chameleon.alt.za> Organization: Chameleon BBS To: ag-directors@alnilam.krl.caltech.edu Our first musician has joined the gang! His name is Brian Pursley (pursley@bsu-cs.bsu.edu). Charles, will you please put him on the Art/Sound mailing list? (Sorry to be such a bother :) Also, can someone send him some info on the ftp sites - I'm not sure the directories I gave him are still valid, and I don't have the member password for the file site. Anyway, here's some info on the guy: ========================================================================== From : pursley@bsu-cs.bsu.edu 22 Jan 95 21:16:00 To : Gert-Jan van Rooyen Subj : Re: Game crew needs musicians ########################################################################## I am a programmer/musician, and have experience with .MODs and .WAVs, as well as experience with C/C++, Asm, and Pascal. If you need some music or sound effects for a game, I would be glad to work on it. I could write some soundtracks and record some sound effects according to what you need, and you could go through them and choose what you like. Brian Pursley pursley@bsu-cs.bsu.edu Ball State University Computer Science Dept. -------------------------------------------------------------------------- ========================================================================== From : pursley@bsu-cs.bsu.edu 25 Jan 95 07:51:00 To : Gert-Jan van Rooyen Subj : Re: Game crew needs musicians ########################################################################## Sounds like a do-able idea with the merging of the differenet sounds/music. Might be possible with .MODs (There's always SOME way). I would be interested in trying to help you with this. I know C very well and also assembly, and could work on a music engine that you described. A list could be maintained that indicates which types of enemies are on the screen (in the area) at any given time. Every so often, the music driver will check the list and use this information as variables to make the music. I think a good common background such as a beat is a good place to start, and then overlay the new, computed sounds ontop of this beat. I still need to think about this some more, but it sounds like an interesting idea. Send me the FTP site so i can get the FAQ and other "stuff" about the game to help me get a better idea. Brian Pursley pursley@bsu-cs.bsu.edu -------------------------------------------------------------------------- Some more music guys will hopefully follow. I've also had a reply from someone who wants to "sell" us music and drivers, in exchange for the right to distribute our game. I can't say I like his attitude much, though. Cheers G-J --- GoldED 2.40 | FidoNet: Gert-Jan van Rooyen 5:7102/129.15 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Fri Jan 13 07:43:56 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id DAA29549 for ; Fri, 13 Jan 1995 03:05:59 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rSgMj-000fIvC; Thu, 12 Jan 95 23:24 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id IAA06288 for ; Fri, 13 Jan 1995 08:22:02 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id IAA19422 for ag-directors@alnilam.krl.caltech.edu; Fri, 13 Jan 1995 08:21:55 +0100 From: Martijn Faassen Message-Id: <199501130721.IAA19422@laurel.stud.phil.ruu.nl> Subject: Wake up call To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Fri, 13 Jan 1995 08:21:55 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5733 Hi all, First an important question: how many people have returned from their holidays yet? It's been rather quiet lately, so I'm wondering. Okay..some of my ideas on evolution in this game now: As you may have noticed, I've been bothered by the use of 'species' in the universe file. I'll now try to explain more clearly why. The way I imagine the game is a field, composed of sectors, in which an amount (as large as possible to still be a playable game) of aliens fly around, and the player, and some other objects. Each alien is, just like the player (in a sense), controlled by its own program. These programs are written in an assembly code like instruction set. Each alien might also have some memory to store temporary variables in, and certainly needs memory to store various pointers in, most importantly the instruction pointer(s). Imagine now that the species/aliens in field ratio is low, meaning, only a few species on a large amount of aliens. If I take it correctly this is what various people here have proposed. This is of course quite memory efficient, because you only need to store the pointers of each separate alien, and possibly some of its memory. The trouble comes when we're trying to let this evolve. The variation among the aliens is actually quite low, so selection won't have too much to work on. That will mean evolution will probably be quite slow, which is not really desirable. My other problem is, how do we *keep* the amount of species low? (if we wanted it at all?) Each time an alien gets offspring, there's a certain chance of mutation; the program of its offspring might be slightly different. So, if this happens, we'll have a new species. (is this so? if not, then how do we determine which individuals are part of a single species at all?) Are species allowed to interbreed? If we disallow species interbreeding, this will stop a lot of potentially good recombination of traits. Oops, no, we'll actually stop *any* recombination of traits, because each individual in a single species has exactly the same program! So, we have to allow species interbreeding. But, each recombination of two species (and *many* recombinations are possible for each two species) will be another new species! What I'm driving at is that the amount of species/amount of aliens ratio will go to 1, no matter what. So we can just as well remove it completely. /* Note, the only way we can keep species, is to make aliens lay batches of eggs, and each egg in one batch is an exact clone of all the other eggs in that batch, so all eggs will be of the same species. This'll slow down evolution too of course (if we allow the offspring to be all different recombinations, we'll get more variation for selection to work on), but it's a way to keep species with an average size the same as the average batch size..If we really want to, that is. (I don't :) */ This doesn't mean we necessarily have to allow unrestricted interbreeding of widely different individuals. If we don't want that, then the alife team should be able to come up with a way to compare the programs in the two individuals, and reject breeding pairs that are too dissimilar. This also doesn't mean we won't *see* any species. If an alien is successful, it gets much offspring, all of which is similar in many ways to the successful alien. So, species will (hopefully) emerge. It might actually be possible to let the player name a certain species, and use the previous alife comparison code to seek out all members of that species. We might use this for nice administration purposes ('hmm..I see that the species RedBastard is reproducing rapidly'). Also, it should be possible for a player to save a 'species' to disk. The player can simply point at an alien which is a member of that species,or perhaps 10 species members to be sure, save those all to disk. If the player wants to seed that species to the field again, the computer can generate clones or mutants of the saved aliens, and drop those on the screen. I'm not exactly sure how this impacts on art/sound. I can imagine art/sound doesn't want to create a new picture for each mutant (or, in the other scheme with species, each new species, which will effectively be each mutant). I'm not exactly sure how the current morphing routine works, but it shouldn't be too hard to adapt it to what I'm going to describe now. The picture of each alien (it's phenotype) is a result of its genotype (the program, the weapons and other traits of the alien). If we want to reflect the weapons/other traits of the aliens directly in the phenotype (the lego approach), then art/sound needs direct access to that. If not, then alife can create a function which creates a 'species number' from the genotype. For example, it looks at certain features of the program, certain weapons that are there or not, and outputs a number. The more similar two aliens are, the more similar their number (or numbers, it doesn't need to be one dimensional). The art/sound picture generator will have this number as input, and will first search look if it already has a picture of an alien with the same, or similar (within a certain range) number. If so, it'll output a pointer to that picture. If not, it'll generate a new picture, and output a pointer to that. Because offspring is generally quite similar to their parents in genotype, the pictures of the offspring might often be the same as the pictures of the parents. (and therefore of the same quasispecies) I hope this all clarified my point of view, questions and comments are of course welcome! Hope to hear from you all (*hint hint*), Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Fri Jan 13 10:55:15 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id KAA29607 for ; Fri, 13 Jan 1995 10:46:46 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rSoFB-000fIvC; Fri, 13 Jan 95 07:48 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/30Dec94-1225PM) id AA17553; Fri, 13 Jan 1995 07:46:55 -0800 From: Charles Ofria Message-Id: <9501131546.AA17553@altair.krl.caltech.edu> Subject: Re: Wake up call To: ag-directors@alnilam.krl.caltech.edu Date: Fri, 13 Jan 1995 07:46:54 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4772 Greetings! Martijn certainly just brought up some excellent points. First a bit of clarification on the terms genotype, phenotype, and species. A genotype is a specific series of code (what he kept refering to as a species) and change to that code (even if its in a line that is never executed) will change the genotype. A phenotype, on the other hand, is simply the results of a set program. If two programs react the same in all situations, they are considered to be of the same phenotype regardless of what their code looks like. Thus if two creature both do everything the same, but in one of them the "guard egg" routine is simply a "guard" subroutine which egg is passed into, while in the other it has a specific "guard egg" and a "guard energy source" and a "guard whatever else" then these creatures are wildly different genotypes, but the same phenotype. Species is somewhere in between the two. All that species means in the real world is that two creatures can mate and produce a successful offspring. Typically both genotype and phenotype will have to be similar for this to work (though granted not always). Using again the examples given above, if two creatures are different only in lines of code that are never executed, they are most certainly of the same species; any crossover between them has lines from one or the other that are never executed, but it just doesn't matter to the final execution of the creature. The second example may or may not have the two creatures of the same species. If after crossover part of the time it calls the "guard" subroutine, and part of the time it has a localize specific guard routine, then the creature does still work and acts similarly to both its parents; they are indeed of the same species. More often, however, I would suspect that the wild differences in the code would make the completely incompatable, and thus not of the same species. Sorry for going off on this - I just a bit excited after finishing a paper on it. Apearing (hopefully) at ECAL'95 will be "Speciation in Single-Stranded Self-Replicating Code" by Chris Adami and yours truly. As promised after our last discussion on species (and only alowing creatures of similar genotypes trying to mate to try to maximize the likelyhood of successful offspring) I have indeed been studying it. So far the results have indicated that by the time approximately 35% of the creatures are different, the chance of successful offspring has reached its minimum (which is almost directly a function of the size of the creatures). I'm not positive how the conference works as far as me releasing the actual paper before it; I'll make sure I find out about that soon. In the meantime, I've still got a decent amount of work left to do on it (I sent in a priliminary copy to be reviewed), so I'll place it on the ftp site as soon as I can. Anyway, back to points useful for you folks. There will be many many different genotypes, all clouded in groups (of species) togeather. To get a rough idea of how many, the number of genotypes is directly proportional to the number of creatures (I think slightly less than 1/10, but I'm not sure off hand). The number of species, however is the 4th root of this. Thus if we have ~1000 creatures at once, we should have just under a hundred genotypes, and about 3 species. We'd need well over 2500 creatures to bring this number up to 4 species. If we seed the soup with many different species, the diversity will last for quite some time, and if we slow the transfer of genetic code thrroughout the soup, we can also increase this number (in other words, since 200 creatures would give us 2 species, 2 pockets of 200 creatures would give us 2 species *each* thus a total of 4 species.) We simply have to make sure that communication is limited so if one super-powerful creature appears, it doesn't completly destroy all the diversity in the soup. If the creatures are very long, and we have a lot of creatures of the same species, with their genotypes differing in only a handful of instructions, we might considder making a "template" genotype, and each creature having a small patch on that to represent its own uniqueness. I'm not sure how well this would work, but its out best chance at makeing these cide pointers really useful. The only time a single genotype will ever have a large number of members is when it was just created and its more successful than those around it, so it spreads quickly. It will be growing far faster than it could possibly be mutated. Well, I guess thats about it for now. I'm sure I was very unclear on some things in here, so please ask any questions. Oh, and perhaps we should move this from the directors list to the alife list? --- Charles From ???@??? Sat Jan 14 07:18:28 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id HAA05094 for ; Sat, 14 Jan 1995 07:11:28 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rT7ND-000fIvC; Sat, 14 Jan 95 04:14 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #8) id m0rT7LC-0004PGC; Sat, 14 Jan 95 14:12 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA03285; 14 Jan 95 06:00:38 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 13 Jan 95 22:03:00 +0200 Subject: Re: Wake up call Message-ID: <052_9501140600@chameleon.alt.za> Organization: Chameleon BBS To: ag-directors@alnilam.krl.caltech.edu On 13 Jan 95, Martijn.Faassen@phil.ruu.nl wrote: > First an important question: how many people have returned from their > holidays yet? It's been rather quiet lately, so I'm wondering. I'm here, waiting for action :) > The way I imagine the game is a field, composed of sectors, in which > an amount (as large as possible to still be a playable game) of aliens fly > around, and the player, and some other objects. Each alien is, just like > the player (in a sense), controlled by its own program. These programs are > written in an assembly code like instruction set. Each alien might also > have some memory to store temporary variables in, and certainly needs > memory to store various pointers in, most importantly the instruction > pointer(s). And probably a small internal stack for "program variables". I guess it depends on what implementation the AI group had in mind. > Imagine now that the species/aliens in field ratio is low, meaning, only > a few species on a large amount of aliens. If I take it correctly this is > what various people here have proposed. This is of course quite memory > efficient, because you only need to store the pointers of each separate > alien, and possibly some of its memory. Except that each alien would still need its own stats (damage, speed, etc.) instruction pointer, and program stack. So it won't be _that_ more memory efficient. > So, we have to allow species interbreeding. But, each recombination of > two species (and *many* recombinations are possible for each two species) > will be another new species! What I'm driving at is that the amount of > species/amount of aliens ratio will go to 1, no matter what. So we can just > as well remove it completely. Agreed. If we're worried about memory, we could always store the info of "remote" aliens (far away from the player) on disk. When a new wave of aliens attacks, some of these alien descriptions can be loaded, interbreeded and new aliens can be produced for the next attack wave. > This doesn't mean we necessarily have to allow unrestricted interbreeding > of widely different individuals. If we don't want that, then the alife team > should be able to come up with a way to compare the programs in the > two individuals, and reject breeding pairs that are too dissimilar. The breeding of very dissimilar aliens will provide offspring that's notably different from both parents - IMO a very good thing. As example, take nature: inbreeding is undesired; cross-breeding allows genetic progress. > I'm not exactly sure how this impacts on art/sound. I can imagine > art/sound doesn't want to create a new picture for each mutant (or, in > the other scheme with species, each new species, which will effectively > be each mutant). I'm not exactly sure how the current morphing > routine works, but it shouldn't be too hard to adapt it to what I'm > going to describe now. > The picture of each alien (it's phenotype) is a result of its genotype > (the program, the weapons and other traits of the alien). If we > want to reflect the weapons/other traits of the aliens directly in the > phenotype (the lego approach), then art/sound needs direct access to that. > If not, then alife can create a function which creates a 'species number' > from the genotype. For example, it looks at certain features of the > program, certain weapons that are there or not, and outputs a number. The > more similar two aliens are, the more similar their number (or numbers, it > doesn't need to be one dimensional). The art/sound picture generator will > have this number as input, and will first search look if it already has a > picture of an alien with the same, or similar (within a certain range) > number. If so, it'll output a pointer to that picture. If not, it'll > generate a new picture, and output a pointer to that. Because offspring is > generally quite similar to their parents in genotype, the pictures of the > offspring might often be the same as the pictures of the parents. (and > therefore of the same quasispecies) This should be quite implementable. With a simple function, we could easily convert an alien's traits into a "species number" that would point to a phenotype that is the combination of the parents' phenotypes. The Julia morphing that Jeff and I experimented with is a good example: if you average two "parent" parameters, you get a texture that is a tween (picture halway between) the two. We could use the same principle to find sufficiently similar phenotypes, and combine them to save memory. Cheers G-J --- GoldED 2.40 | FidoNet: Gert-Jan van Rooyen 5:7102/129.15 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Mon Jan 16 15:58:38 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA21428 for ; Mon, 16 Jan 1995 14:39:32 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rTxIf-000fIvC; Mon, 16 Jan 95 11:41 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #8) id m0rTxGW-0004GJC; Mon, 16 Jan 95 21:39 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA03307; 16 Jan 95 10:08:54 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 15 Jan 95 10:35:01 +0200 Subject: Re: pheno-geno species confusion Message-ID: <826_9501161008@chameleon.alt.za> Organization: Chameleon BBS To: ag-directors@alnilam.krl.caltech.edu On 13 Jan 95, Martijn.Faassen@phil.ruu.nl wrote: > Actually, thinking about this..the more memory is available, the smaller > we can set the range in which still the same picture is used. Also, if > the number of species happens to increase, we can simply increase the > range, so we only have to use roughly the same amounts of pictures! Good idea... But then we'll have to devise a formula for converting an alien's genotype into a seed number for the picture. The basic principle should be that if the alien differs only a little from another alien, their respective seed numbers should also only differ a little. Any suggestions on how we'll manage that? Cheers G-J --- GoldED 2.40 | FidoNet: Gert-Jan van Rooyen 5:7102/129.15 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Tue Jan 24 07:12:34 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id GAA26309 for ; Tue, 24 Jan 1995 06:58:36 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rWjvN-000fIvC; Tue, 24 Jan 95 04:00 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #8) id m0rWjtI-0004TiC; Tue, 24 Jan 95 13:58 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA03405; 24 Jan 95 06:01:21 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 23 Jan 95 19:40:01 +0200 Subject: Re: This week. Message-ID: <7d4_9501240601@chameleon.alt.za> Organization: Chameleon BBS To: ag-directors@alnilam.krl.caltech.edu > (c) assign various portions of it to your groups (with 'deadlines') Good. Something to motivate the groups (like deadlines) can only do good. > Art/Sound - SOUND! Gert-Jan was talking about going to the net to search > out a sound group. I have done so, and at the moment I'm "interviewing" some potential musicians to see if they'd like joining us. As soon as any of them gives the OK, I'll inform Charles to throw their names onto the mailing list, and post info on them to the directors. Charles, please do me a favour and put my address on the list for the Art/Sound group. I'll see what I can get the music guys to do for so long. Meanwhile, the various groups can let their minds go about sound fx and the like. Once we have a movie sequence, the musicians can start composing an appropriate score. > The way our sound will work is still yet to be > decided. A mod or midi format? At the moment I'm corresponding with musicians proficient in both of these formats. Maybe the best approach would be to have MOD music and recorded sound effects, and use FM for the "whale sounds". I know that this would work on SB compatibles... But would it work on all other cards? > Also on the Art end, a .mov format > needs to be decided upon. Also, defines for what the movie sections > will entail, so the Arties can begin raytracing... My mouse-drawn art is disgustifyingly sick, but I can do a raytrace or two... So let the Art-Sounders know what you want. > FE-??? - Decisions need to be made on the gfx mode for each system. All in > all I think that all of the FE fols should chat in the FE-PCX group > until basic ideas are decided, then machine specific implementations > of those will be discussed afterward. OK. What have the Amigas and Macs been doing so far? > --- [SNIP] --- > This method allows for fairly involved sectors, which have an order to > them and also provide convienient break-points to show our neat movies. The method sounds good. > The LOAD/SAVE ALIEN options allow us to display a picture of an alien and > rotate thru all of the current types of aliens..letting the player SAVE > an alien to disk, or load one in it's place. This way players could > exchange aliens via FTP, BBS and disk alike! Nice idea... OK, so let's get going! Cheers G-J --- GoldED 2.40 | FidoNet: Gert-Jan van Rooyen 5:7102/129.15 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Sat Jan 21 23:10:05 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id XAA15975 for ; Sat, 21 Jan 1995 23:02:22 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rVtXy-000fIvC; Sat, 21 Jan 95 20:05 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA19286; Sat, 21 Jan 95 20:03:44 PST Date: Sat, 21 Jan 1995 20:03:43 -0800 (PST) From: Gregory Glen Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: This week. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm sorry for flooding your mailboxes with msgs today. Here's the plan. We've got a number of tasks before us: (a) revise Universe.h to our liking, and release it to the groups (b) decide an order for the work to be finished AND... (c) assign various portions of it to your groups (with 'deadlines') So here's my thoughts on each group... Universe - Adrian, post the latest copy of the Universe.h so we can edit it...etc. Then get the main () written and organize an order for which routines should be done when. Alife - Charles, Martijn, please figure out what variables you will need in the global header...the structures etc. Append these to the universe.h that Adrian will kindly post again for us. Art/Sound - SOUND! Gert-Jan was talking about going to the net to search out a sound group. The way our sound will work is still yet to be decided. A mod or midi format? Also on the Art end, a .mov format needs to be decided upon. Also, defines for what the movie sections will entail, so the Arties can begin raytracing... FE-??? - Decisions need to be made on the gfx mode for each system. All in all I think that all of the FE fols should chat in the FE-PCX group until basic ideas are decided, then machine specific implementations of those will be discussed afterward. Again, like the other groups, functions need to be given to various members to code. Plot - Martijn, I think we'll be using a variation of your Van hootle-woogie Project (sorry about the butchered name! :) scheme. It has many merits, and helps us excuse our alien permiscuity by saying they're bizzare alien/probes sort of thingies. Please scribble together a revised version of a good plot and post it to the directors. THE GAME. Adrian and I discussed the game-flow of the game and came with a very good compilation of ideas. This is kinda nebulus but it'll give you an idea, main () will help out a bit more. INTRO SEQUENCE - The first part o our plot story. TITLE SCREEN ! - Our name of the game in big, flashy letters. CREDITS - Our names in big flashy letters. MAIN MENU - (Playloop state) [RESUME GAME] - only if a game is in progress. NEW GAME LOAD GAME SAVE GAME OPTIONS - NON hardware based options. all hardware based options are stored in the config file. SOUND LEVEL SOUND FX LEVEL GOD MODE - On or off LOAD ALIEN SAVE ALIEN [all the rest of the options TBD] REPLAY STORY - replays the current movie associated with the current level ... Anything else? QUIT EXIT SEQUENCE - if any, perhaps an advertisement or 'goodbye' msg. The GAME will procede as follows : (1) If a NEW game, or NEW LEVEL then dispay SPACESECTOR chart... /-----------\ | 7| 6| 5| 4| |--+--+--+--| | 6| 5| 4| 3| |--+--+--+--| | 5| 4| 3| 2| |--+--+--+--| | 4| 3| 2| 1| \-----------/ You'll start the game in the lower-left hand corner of Space. You would then go defeat that sector of space. Several aliens from that sector would bleed into the adjacent sectors... Once you defeat a sector (probably about 30min to and hour for the first few sectors...pretty involved, lots of time for evolution), you would return to this map and choose an adjacent sector to go for next. Whenever you go into a sector within a new 'band' of space (the numbers represent the various bands), it would display a new movie, unfolding our plot more. Movie 1 would be the intro, movie 7 would be the 'about to enter the alien hive' portion, and movie 8 would be the finale'...'you win!' movie. You can't advance into a new band of space until all of the previous bands (including the current one) have been cleared. Thus a player would have to brawl his way thru 16 sectors of space to 'win'...each band giving more 'starting cash' to the aliens, and also inheriting aliens from previous sectors. As you go thru the bands of space, the time to clear them would increase, and the final sector would probably take quite some time to clear. You could bring your extra lives with you to the next sector of course. This method allows for fairly involved sectors, which have an order to them and also provide convienient break-points to show our neat movies. If one were to switch it to GOD mode, then they would be restricted to the current sector, the game would keep feeding in new species faster than the player could kill them or something similar to provide the Alife fanatic to play around for ours on end, switching from alien to alien, etc. playing a sector would involve starting with a bunch of 'eggs' (or whatever the plot calls them) and you can drag those around, put them on asteroids for safety or whatever. You would follow the game play we've pretty much decided upon, that is : an alien decided to lay an 'egg', this then must be fertilized by another alien...the player could go in and try to get it first, and then he'd have to drag it to his eggs or perhaps some other spot. Eventually, you'd clear the sector of aliens, and move on to the sector map again to choose your next conquest. The LOAD/SAVE ALIEN options allow us to display a picture of an alien and rotate thru all of the current types of aliens..letting the player SAVE an alien to disk, or load one in it's place. This way players could exchange aliens via FTP, BBS and disk alike! The MENU screens will be generated by the Art/Sound group. Each menu bar would be in certain coordinates on a 640x480 screen (the largest we'll support), the FE_get_cursur_pos (for keyb, mouse, or joystick...whatever controler) routine would return a value scaled to these coordinates. Allowing the Universe group to manage it's menus easier. Plus having the Art/Sound group draw the pics, they will look the same on all systems... I'm going to put together a specs file on what all of the various menu options will be and the flow of things and release it with the final Universe.h draft. Mull these ideas over and see if you have any alterations you might like to see. The main thing I want to accomplish this week is re-activating the groups into furvent discussion and prepare for the beginning of the coding (which is real close). I'll be in touch... Talk to ya later -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Fri Jan 27 16:50:32 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id PAA28022 for ; Fri, 27 Jan 1995 15:38:48 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rXwZt-000fIvC; Fri, 27 Jan 95 11:43 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id UAA06458 for ; Fri, 27 Jan 1995 20:40:30 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id UAA00909 for ag-directors@alnilam.krl.caltech.edu; Fri, 27 Jan 1995 20:40:26 +0100 From: Martijn Faassen Message-Id: <199501271940.UAA00909@laurel.stud.phil.ruu.nl> Subject: UNIVERSE.H Companion (comments) To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Fri, 27 Jan 1995 20:40:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6188 > // ** GENOTYPE ** > > This is the 'batch' that an alien belongs to. It's more fully explained > in the 'Game_Structure.x' file. Every time an egg hatches, it will release > 10 or so (random within certain limits, set by the Alifers) aliens who > share the same pictures, but have slightly different stats and behaviours. So a single egg contains more than one alien? I wasn't aware of this.. Should we do this? By doing this we might indeed need less pictures, but it'll seriously restrict the diversity of the aliens. I'm not actually sure what it'll will do to evolution, because that's always tricky to do, but I expect it won't be good.. My main objection is that you seriously restrict the possible combinations of genetic material this way, and this is bad, because less new behaviours will pop up, and so evolution will go slow. I'll try to explain. First imagine the case with 1 egg, 10 aliens which are (almost) the same behaviourily. This means that we have 10 clones, and each clone is the same combination of the genetic material of the 'father' and the 'mother' of the alien. Terminology note: the father of the alien is the one who fertilized the egg, the mother is the one who layed the egg. I believe most fish do it this way (release egg and sperm into the water). As of now, aliens can fullfill both the father and the mother functions, unless we implement gender, which should be very interested to do, but is of later concern, and shouldn't be too hard to add to the current system. Anway, now imagine the case with 1 alien per egg. The mother can scatter the 10 eggs, which gives more possibilities for survival, if one egg gets destroyed, there's still 9 others that can survive. Also, if the alien mother doesn't have enough energy to lay 10 eggs, she can lay only 5 instead, another advantage. Each egg can be fertilized by a *different* father (hey, even the mother her?self can be the father!), but even if the same father fertilizes all eggs, many combinations of the genes can arise. (because, in the egg is 50% of the genetic material of the mother, and 50% of genetic material of the father is used to fertilize each egg..but *which* 50% isn't predetermined, so really many many combinations can come forward..consider how much a human tends to *differ* from its siblings..actually, basically, you're just as related to a parent as to a sibling as to a child, namely 50% of the genetic material.) I think we should be able to implement a basic genetics system like this, and have done some thinking on this (and will do some writing on it too). Now, memory considerations: We don't want a separate picture for each alien. So, we want aliens to share pictures, to spare memory. The clutch solution (10 aliens with same phenotype but also genotype! per egg) is one solution, but it seems to inhibit evolution. Therefore, I proposed the phenotype number solution, a system which classifies each alien in a group to which it's related. Each group can share the same picture. This system is more flexible, because if we see we have memory left for more pictures, we can simply alter the group requirements, make them more stringent, so aliens will fall apart in more groups. If we have not enough memory, we can broaden the groups, so more aliens will fall in the same group. This system can also be used to determine the gains an alien gets for shooting another alien: if an alien kills a relative, it'll get less. Note that the clutch system can only implement this for clutch mates, while parents are just as much relatives, and kids! (actually, we might let this simply evolve: give same reward for killing relative as for killing nonrelative, but enable the aliens to check if the one they're shooting at is a relative, will discourage the aliens from shooting their relatives, because genetic code that doesn't kill its copies in other aliens has more survival chance (because the copies survive too) than genetic code that destroys its own copies. We'll see if this is enough all by itself. Or perhaps we can make an option which we can turn on and off) > A genotype can act as a group. An index to the parent genotype is given > in the genotype structure, so 'cousin' aliens can detect each other and > perhaps act together. Again, any info specific to a 'batch' of alien > offspring will be stored here. This would fit right into my scheme, and it would work all the ways too. Children can recognize parents as related, parents can recognize children as related, siblings can recognize other siblings are related, etc. > // ** OBJECT ** > > This is the part of the alien that is their own stuff. Each alien and object > etc. is defined by one of these. Also it is in need of more stuff in there. > (mostly Alife group stuff...) Most of the alife stuff can be completely seperate from the rest of the code. See below. > //--Alife-------------------------------------------------------------------- > long AI_AlienMove (); Better change this into something like: long Al_AlienExecute(); Executes alife code in all the aliens. Each alien should have something like a keypress buffer, accessible by alife (to fill it) and universe (to execute it). Any ideas on this? It can probably use the keypress scheme. > short AI_CreateHybrid (); > > Creates a new hybrid. > We would probably need functions that universe can call when: creating an egg (depositing the genetic material is the alife part of it) fertilizing an egg (again, alife part is the genetic material) and hatching an egg (the alife part would be mixing the genetic material of the father and mother) > short AI_CreateObject (); > > Creates a new object. (for making asteroids, but more importantly...new > weapons...) I'll check universe.h after I send off the mail to see what this does again. :) > Add/Subtract/Revise/Hack/Slash this file. I'll be taking submissions for > a while, but I want to get this finished up. Talk to you later. -=GT=- > I've added/substracted/revise/hacked/slashed the file, though more will probably still be coming. Good luck, Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Jan 30 12:09:15 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA28031 for ; Mon, 30 Jan 1995 12:01:39 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rYzWP-000fIvC; Mon, 30 Jan 95 09:04 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id SAA18483 for ; Mon, 30 Jan 1995 18:00:35 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id SAA20964 for ag-directors@alnilam.krl.caltech.edu; Mon, 30 Jan 1995 18:00:29 +0100 From: Martijn Faassen Message-Id: <199501301700.SAA20964@laurel.stud.phil.ruu.nl> Subject: UNIVERSE.H Companion (comments) (fwd) To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 30 Jan 1995 18:00:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1332 > > > // ** GENOTYPE ** > > > > > > This is the 'batch' that an alien belongs to. It's more fully explained > > > in the 'Game_Structure.x' file. Every time an egg hatches, it will release > > > 10 or so (random within certain limits, set by the Alifers) aliens who > > > share the same pictures, but have slightly different stats and behaviours. > > > > So a single egg contains more than one alien? I wasn't aware of this.. > > Should we do this? > > Why not? Batches of >1 egg are still allowed (and I don't think we should > limit the aliens by having non-life "energy" which is used when an alien does > things, thus there will be no immediate difference to an alien whether it > lays 1 or 10 eggs). > Huh? Are you implying laying 10 eggs costs as much as laying a single egg? Any reason then why aliens wouldn't be laying eggs continuously? What is 'non-life energy'? what's 'life energy'? I'm not quite clear on terminology here. But, generally, doing things should cost. Only thing I'd like is that the aliens are just as limited as the human player, not more, and not less. This would mean laying eggs should cost for the human too, otherwise I know what *I* would do. :) Anyway, some clarifications would be appreciated. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Jan 30 12:29:14 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA02047 for ; Mon, 30 Jan 1995 12:21:53 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rYzqD-000fIvC; Mon, 30 Jan 95 09:24 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id SAA18843 for ; Mon, 30 Jan 1995 18:20:46 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id SAA21724 for ag-directors@alnilam.krl.caltech.edu; Mon, 30 Jan 1995 18:20:44 +0100 From: Martijn Faassen Message-Id: <199501301720.SAA21724@laurel.stud.phil.ruu.nl> Subject: Re: UNIVERSE.H - preview - ver 0.02 (fwd) To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 30 Jan 1995 18:20:43 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3542 > Sounds reasonable. I still think a total time is better... Keep in > mind that we'll be handling alien AI every screen redraw as well, just > like the player. Having a total time allows us to skip that alien for a > few re-draws, where if we had several times, we'd have to calc a new > action from scratch anyway...making sense am I? Well, the way I see it, each alien's alife code is executed one or a few steps further each tick (or screen redraw, or whatever). But, the alife code doesn't necessarily have to 'press' any keys at all, then! It might just be looking, analysing what it's seeing, or whatever else occurs (sometimes it might be doing nothing useful at all!) The point of using somekind of alien behaviour code which can be executed in steps is to prevent alife from holding up the game. But, I was assuming each alien gets executed each tick. The use of the alien doing things like sending multiple key press combinations (the total bitstring of keypresses) to its keyboard buffer, which is executed by universe, means that it can work in advance, put some things in the buffer already, so that it can do something else in the mean time. (we might make it so that the alien can edit the buffer that's already written, like a motor command being interrupted when something weird comes up, in humans and animals)a Anyway, this kind of keyboard buffer might be part of alife completely too, if we want, the universe buffer might just be 1 bitstring big. :) I'm wandering away from my main story, just keep in mind that I was expecting some (small) amount of time allocated to each alien each tick, to let it execute a few more instructions of its program. Alife does *not* work like this: keyboardbitstring = move_alien(aliennumber); Instead it would work like somewhat like this: keyboardbitstring[aliennumber] is a global variable accessible both by alife and universe. (universe only reading, alife read/write) each tick, each alien in the universe is called: for (aliennumber = 0; aliennumber <= alienmax; aliennumber++) { execute_alien(aliennumber); } Then universe can simply read out all keyboardbitstrings and do the actions in there. The aliens may or not update their keyboardbuffer strings when being executed. > > > Do we really want to keep track of energy? If so, should we also include > > yes. Agreed. > > > an intrinsic "energy regeneration rate", or do we want to have eating be the > > only way to get more fuel? And if an alien runs out of energy, does it drift > > I think they ought to be able to regenerate just by existing (slowly) > eating etc. just speeds up the process. This helps limit continuous > breeding and firing. Thrust doesn't take energy...we don't want a bunch > of stagnant aliens. We could make this options to be turned on and off very easily, simply have a regeneration rate which can be set to 0, and energy costs for all kinds of purposes, including thrust, which can be set to 0 or other values. > > > forever or immediately die? > > > No they just can't fire or breed etc. The key thing for a no-energy left > alien to do is...run away! If you have the right options set. :) Note please that the player should in may opinion have exactly the same energy scheme, following the general principle of equility of alien capabilities and that of the player. > > > Now to the next Adrian response....-=GT=- > I'll go further through my email also. :) Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Jan 30 12:39:30 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA02450 for ; Mon, 30 Jan 1995 12:23:37 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rYztR-000fIvC; Mon, 30 Jan 95 09:28 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id JAA22378 for ag-directors@alnilam.krl.caltech.edu; Mon, 30 Jan 1995 09:24:42 -0800 From: Adrian Tymes Message-Id: <199501301724.JAA22378@mcl.mcl.ucsb.edu> Subject: UNIVERSE.H Companion (comments) (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Mon, 30 Jan 1995 09:24:42 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 772 > Huh? Are you implying laying 10 eggs costs as much as laying a single egg? > Any reason then why aliens wouldn't be laying eggs continuously? > > What is 'non-life energy'? what's 'life energy'? I'm not quite clear on > terminology here. But, generally, doing things should cost. Only thing I'd > like is that the aliens are just as limited as the human player, not more, > and not less. This would mean laying eggs should cost for the human too, > otherwise I know what *I* would do. :) non-life energy: energy used for firing, laying eggs, etc. life energy: energy used up when the alien (or player) is hit. Even if we have both types of energy (which, after re-reading 0.02, it seems that we will), evolution will probably favor the aliens that lay many eggs. From ???@??? Mon Jan 30 12:59:13 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA08303 for ; Mon, 30 Jan 1995 12:51:37 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZ0Im-000fIvC; Mon, 30 Jan 95 09:54 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id SAA19417 for ; Mon, 30 Jan 1995 18:50:54 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id SAA22963 for ag-directors@alnilam.krl.caltech.edu; Mon, 30 Jan 1995 18:50:51 +0100 From: Martijn Faassen Message-Id: <199501301750.SAA22963@laurel.stud.phil.ruu.nl> Subject: UNIVERSE.H Companion (comments) (fwd) To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 30 Jan 1995 18:50:50 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 589 Adrian wrote: > non-life energy: energy used for firing, laying eggs, etc. > > life energy: energy used up when the alien (or player) is hit. > > Even if we have both types of energy (which, after re-reading 0.02, it > seems that we will), evolution will probably favor the aliens that lay > many eggs. > Why? Maybe laying an egg is too expensive to spill your energy on? Or maybe some other strategies, laying a few eggs but protecting them well are effective too? It's kind of hard to say. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Jan 30 13:19:32 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA12231 for ; Mon, 30 Jan 1995 13:10:00 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZ0Xc-000fIyC; Mon, 30 Jan 95 10:09 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/30Dec94-1225PM) id AA10843; Mon, 30 Jan 1995 10:06:22 -0800 From: Charles Ofria Message-Id: <9501301806.AA10843@altair.krl.caltech.edu> Subject: Re: UNIVERSE.H - preview - ver 0.02 To: ag-directors@alnilam.krl.caltech.edu, ag-alife@alnilam.krl.caltech.edu Date: Mon, 30 Jan 1995 10:06:22 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1063 > Sounds reasonable. I still think a total time is better... Keep in > mind that we'll be handling alien AI every screen redraw as well, just > like the player. Having a total time allows us to skip that alien for a > few re-draws, where if we had several times, we'd have to calc a new > action from scratch anyway...making sense am I? Well, the problem here (which Martijn pointed out clearly) is that aliens need to be able to react immediately to their environment. To look at an extreme case, it is pointless for an alien to get exectued continuously for 10 minutes, and then ignored for the next hour while to player comes over and kills it. I do like the idea of a "keyboard buffer" for the aliens. Basically this buffer would be "if nothing changes, do this:" Then, the alien can scan for changes (perhaps planning ahead???) and if any change does occur, it can react immediately. If there were an unchangeable keyboard buffer, it would be just as bad as executing an alien for a while, and then ignoring it for a while. --- Charles From ???@??? Mon Jan 30 13:29:35 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA12870 for ; Mon, 30 Jan 1995 13:13:11 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZ0S0-000fIvC; Mon, 30 Jan 95 10:03 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/30Dec94-1225PM) id AA10715; Mon, 30 Jan 1995 10:00:34 -0800 From: Charles Ofria Message-Id: <9501301800.AA10715@altair.krl.caltech.edu> Subject: UNIVERSE.H Companion (comments) (fwd) To: ag-directors@alnilam.krl.caltech.edu, ag-alife@alnilam.krl.caltech.edu Date: Mon, 30 Jan 1995 10:00:34 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 556 > Huh? Are you implying laying 10 eggs costs as much as laying a single egg? > Any reason then why aliens wouldn't be laying eggs continuously? I believe what we had decided on was that when you lay an egg, you can place any ammount of energy you want into it. As time goes on, then energy decays, thus the more energy you put in, the longer the egg can last before it "spoils". Thus if you create too many eggs with not enough energy in them, they will all die out before they can be fertilized, and you would have wasted the energy. --- Charles From ???@??? Mon Jan 30 13:29:36 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA13892 for ; Mon, 30 Jan 1995 13:19:01 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZ0is-000fJ0C; Mon, 30 Jan 95 10:21 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id TAA19880 for ; Mon, 30 Jan 1995 19:17:42 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id TAA24094 for ag-directors@alnilam.krl.caltech.edu; Mon, 30 Jan 1995 19:17:40 +0100 From: Martijn Faassen Message-Id: <199501301817.TAA24094@laurel.stud.phil.ruu.nl> Subject: UNIVERSE.H Companion (comments) (fwd) eggs To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 30 Jan 1995 19:17:40 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1134 > > > Huh? Are you implying laying 10 eggs costs as much as laying a single egg? > > Any reason then why aliens wouldn't be laying eggs continuously? > > I believe what we had decided on was that when you lay an egg, you can place > any ammount of energy you want into it. As time goes on, then energy decays, > thus the more energy you put in, the longer the egg can last before it > "spoils". We might also use the amount of energy put in influence the amount of investment the embryonic alien can make in various things (weapons, armor, thrust, etc) instead. This would provide a rather natural mechanism for 'boss aliens'. Still, the spoil thing can be something too..Maybe both somehow? > > Thus if you create too many eggs with not enough energy in them, they will > all die out before they can be fertilized, and you would have wasted the > energy. Agree. About the same story goes for investment energy, in this case the young aliens would be too weak to survive before reproducing. (waste of energy also) > --- Charles > Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Jan 30 14:29:29 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA24582 for ; Mon, 30 Jan 1995 14:15:19 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZ1cI-000fIyC; Mon, 30 Jan 95 11:18 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id UAA20995 for ; Mon, 30 Jan 1995 20:14:41 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id UAA26422 for ag-directors@alnilam.krl.caltech.edu; Mon, 30 Jan 1995 20:14:39 +0100 From: Martijn Faassen Message-Id: <199501301914.UAA26422@laurel.stud.phil.ruu.nl> Subject: Re: UNIVERSE.H Companion (comments) (eggs) To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 30 Jan 1995 20:14:38 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 806 > >We might also use the amount of energy put in influence the amount of > >investment the embryonic alien can make in various things (weapons, armor, > >thrust, etc) instead. This would provide a rather natural mechanism for > >'boss aliens'. Still, the spoil thing can be something too..Maybe both > >somehow? > > How about having the first one that drops off the egg invest it with some > energy. This level slowly drops, until the egg is fertilized. When the > father fertilizes it, he gives it some energy, which is added to the > existing level...and this number is used to determine what the embryo can > develop. Something like this sounds fine to me. > > Michael Mitchener > st944m5h@post.drexel.edu > Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Jan 30 14:29:31 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA24991 for ; Mon, 30 Jan 1995 14:18:10 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZ1dR-000fIzC; Mon, 30 Jan 95 11:19 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA24397 for ; Mon, 30 Jan 1995 14:14:24 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 30 Jan 1995 14:21:00 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: UNIVERSE.H Companion (comments) (fwd) eggs >We might also use the amount of energy put in influence the amount of >investment the embryonic alien can make in various things (weapons, armor, >thrust, etc) instead. This would provide a rather natural mechanism for >'boss aliens'. Still, the spoil thing can be something too..Maybe both >somehow? How about having the first one that drops off the egg invest it with some energy. This level slowly drops, until the egg is fertilized. When the father fertilizes it, he gives it some energy, which is added to the existing level...and this number is used to determine what the embryo can develop. PS-sorry about the double mail, Martijn... --- Michael Mitchener st944m5h@post.drexel.edu Michael Mitchener st944m5h@post.drexel.edu From ???@??? Tue Jan 31 14:37:04 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA06273 for ; Tue, 31 Jan 1995 14:21:18 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZOAe-000fIvC; Tue, 31 Jan 95 11:23 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #8) id m0rZO7c-0004WhC; Tue, 31 Jan 95 21:20 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA03503; 31 Jan 95 19:26:31 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 30 Jan 95 23:06:00 +0200 Subject: Re: UNIVERSE.H Companion Message-ID: <5ad_9501311926@chameleon.alt.za> Organization: Chameleon BBS To: ag-directors@alnilam.krl.caltech.edu >> > These will be getting bumped to the FE_'s unless someone can reason me >> > why they're system independant...so don't get too fixed on the AS_ >> > prefix, for they will likely be labeled with FE_... >> But from where are the sound routines going >> to be called? Only from FE_Update, or from any of the universe routines >> as well? If it's to be called from FE-Update, it should be made FE >> local. But it seems to me that UNIVERSE.C would need access to these >> routines as well. > That's why they'll be in Universe.h...as FE_... routines. Anything that > can/will be accessed by more than one group (non-universe) or get's > called from another group by the universe is considered a global or in > our case a 'universal' :) routine. So yes, they will be FE specific > -and- globally accessable, thus put in Universe.h... Ahh, sorry, I misunderstood you the first time :) Cheers G-J --- GoldED 2.40 | FidoNet: Gert-Jan van Rooyen 5:7102/129.15 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Tue Jan 31 14:46:47 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA09607 for ; Tue, 31 Jan 1995 14:39:37 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZOTX-000fIvC; Tue, 31 Jan 95 11:42 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id LAA16254 for ag-directors@alnilam.krl.caltech.edu; Tue, 31 Jan 1995 11:39:46 -0800 From: Adrian Tymes Message-Id: <199501311939.LAA16254@mcl.mcl.ucsb.edu> Subject: Object size To: ag-directors@alnilam.krl.caltech.edu Date: Tue, 31 Jan 1995 11:39:46 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 194 Would it be too limiting to limit the biggest object to be no bigger than 1/2 of a sector by 1/2 of a sector? If we do this, collision detection only has to check one sector for each object. From ???@??? Tue Jan 31 15:14:05 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id PAA13813 for ; Tue, 31 Jan 1995 15:05:32 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZOek-000fIzC; Tue, 31 Jan 95 11:54 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id LAA19974 for ag-directors@alnilam.krl.caltech.edu; Tue, 31 Jan 1995 11:51:21 -0800 From: Adrian Tymes Message-Id: <199501311951.LAA19974@mcl.mcl.ucsb.edu> Subject: Object size (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Tue, 31 Jan 1995 11:51:21 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 638 > > Would it be too limiting to limit the biggest object to be no bigger than > > 1/2 of a sector by 1/2 of a sector? If we do this, collision detection > > only has to check one sector for each object. > > > > How many screenfulls is half a sector? It sounds big enough by a large > margin to me.. Depending on whether FE displays the 4 sectors surrounding the player, or only a portion of 1 sector, this will be at least 1/3 of a screen by 1/3 of a screen...if all 4 sectors are shown, the screen could be: A-E-B-F | | | | I-M-J-N | |X| | C-G-D-H | | | | K-O-L-P Sectors=ABCD,EFGH,IJKL,MNOP,player at X (possibly filling MJGD) From ???@??? Tue Jan 31 15:14:07 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id PAA13862 for ; Tue, 31 Jan 1995 15:05:47 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZOZW-000fIyC; Tue, 31 Jan 95 11:49 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id UAA19982 for ; Tue, 31 Jan 1995 20:45:41 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id UAA23524 for ag-directors@alnilam.krl.caltech.edu; Tue, 31 Jan 1995 20:45:37 +0100 From: Martijn Faassen Message-Id: <199501311945.UAA23524@laurel.stud.phil.ruu.nl> Subject: Object size To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 31 Jan 1995 20:45:36 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 382 > > Would it be too limiting to limit the biggest object to be no bigger than > 1/2 of a sector by 1/2 of a sector? If we do this, collision detection > only has to check one sector for each object. > How many screenfulls is half a sector? It sounds big enough by a large margin to me.. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Tue Jan 31 15:14:09 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id PAA13842 for ; Tue, 31 Jan 1995 15:05:42 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZOZU-000fIvC; Tue, 31 Jan 95 11:49 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id LAA18087 for ag-directors@alnilam.krl.caltech.edu; Tue, 31 Jan 1995 11:45:52 -0800 From: Adrian Tymes Message-Id: <199501311945.LAA18087@mcl.mcl.ucsb.edu> Subject: UNIVERSE.H Companion (comments) (fwd) eggs (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Tue, 31 Jan 1995 11:45:51 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 918 > > > Huh? Are you implying laying 10 eggs costs as much as laying a single egg? > > > Any reason then why aliens wouldn't be laying eggs continuously? > > > > I believe what we had decided on was that when you lay an egg, you can place > > any ammount of energy you want into it. As time goes on, then energy decays, > > thus the more energy you put in, the longer the egg can last before it > > "spoils". > > We might also use the amount of energy put in influence the amount of > investment the embryonic alien can make in various things (weapons, armor, > thrust, etc) instead. This would provide a rather natural mechanism for > 'boss aliens'. Still, the spoil thing can be something too..Maybe both > somehow? Sure...then the only way boss aliens can be formed is if a high-energy egg is fertilized quickly. Should we also have the amount of energy control the number of aliens that each egg produces? From ???@??? Tue Jan 31 22:16:42 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id WAA04142 for ; Tue, 31 Jan 1995 22:05:32 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rZUxx-000fIvC; Tue, 31 Jan 95 18:38 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id SAA12388; Tue, 31 Jan 1995 18:35:34 -0800 From: Adrian Tymes Message-Id: <199502010235.SAA12388@mcl.mcl.ucsb.edu> Subject: Collision detection thing I found (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Tue, 31 Jan 1995 18:35:34 -0800 (PST) Cc: ag-universe@alnilam.krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 944 > int CheckCollision ( rect r1, rect r2 ) /* change to pointers if you wish */ > { > if ( ( r1.x2 < r2.x1 ) && ( r1.x1 > r2.x2 ) && /* check left/right */ > ( r1.y2 < r2.y1 ) && ( r1.y1 > r2.y2 ) ) /* check top/bottom */ > return 1; /* collision! */ > return 0; /* miss */ > } > > ----------------------------------------------------------------------------- > > This is much better than the vertex check which can miss collisions of the > form: > r1 ___ > | | > r2 __|___|__ > | | | | > |__|___|__| > | | > |___| > > > Where clearly a collision has occurred, yet no vertex lies within the bounds > of another rectangle... And using a vertex check it will take you 16 compares > to come to this false conclusion. So we should store 4 coordinates for each object, corresponding to its top left, top right, bottom left, and bottom right corners? From ???@??? Thu Feb 02 11:28:14 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id LAA10738 for ; Thu, 2 Feb 1995 11:18:20 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0ra4Ik-000fIvC; Thu, 2 Feb 95 08:22 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id RAA12491 for ; Thu, 2 Feb 1995 17:19:03 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id RAA06587 for ag-directors@alnilam.krl.caltech.edu; Thu, 2 Feb 1995 17:19:01 +0100 From: Martijn Faassen Message-Id: <199502021619.RAA06587@laurel.stud.phil.ruu.nl> Subject: Absence next week To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 2 Feb 1995 17:19:00 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 584 Hello everybody, Unfortunately I will have no net access next week, as I'll be skiing in Austria. I hope Charles (though he's busy) can take over the alife group during that period. I'll be back completely the week after that though, and don't stop anything because of me. :) Hopefully I'll also soon have my new PC, so I can start doing some serious programming (currently I only have my ancient XT, and access to a 486 only occasionally, but that'll change. :) Good luck, and keep going, Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Thu Feb 02 17:32:00 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id RAA14580 for ; Thu, 2 Feb 1995 17:18:16 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0ra9uv-000fIzC; Thu, 2 Feb 95 14:22 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #8) id m0ra9rw-0004WaC; Fri, 3 Feb 95 00:19 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA03551; 02 Feb 95 21:15:33 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 02 Feb 95 12:12:05 +0200 Subject: Absence Message-ID: <05f_9502022115@chameleon.alt.za> Organization: Chameleon BBS To: ag-directors@alnilam.krl.caltech.edu I'll be leaving this afternoon for the start of the varsity term. My student internet account won't be active until a week or two from now, and as I'm staying in res, I won't have access to my computer for the first few weeks. So it'll be quiet from my side for a while (hopefully not too long). Sorry about that. :-( Cheers G-J --- GoldED 2.40 | FidoNet: Gert-Jan van Rooyen 5:7102/129.15 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Fri Feb 10 01:56:46 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id BAA04963 for ; Fri, 10 Feb 1995 01:40:11 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rcp4j-000fJ4C; Thu, 9 Feb 95 22:43 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id WAA22134 for ag-directors@alnilam.krl.caltech.edu; Thu, 9 Feb 1995 22:41:22 -0800 Date: Thu, 9 Feb 1995 22:41:22 -0800 From: Adrian Tymes Message-Id: <199502100641.WAA22134@mcl.mcl.ucsb.edu> To: ag-directors@alnilam.krl.caltech.edu Subject: Idea for movie 1 After re-reading the plot, a question immediately came to mind: the probes were launched three years ago...so why are they only now starting to attacK? Perhaps in movie 1, this could be stated. Also, what if the player were given a ship that was supposed to imitate the probes after all of the obviously-human-built ships were trashed, to make the probes not constantly attack the player? Breeding could be added in after round 1 (the aliens on the first round will be wimps anyway) as an improvement gained by observing the aliens...more improvements would require captured aliens/ alprobes. From ???@??? Fri Feb 10 01:56:49 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id BAA05666 for ; Fri, 10 Feb 1995 01:49:47 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rcpCY-000fJ4C; Thu, 9 Feb 95 22:51 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA02598; Thu, 9 Feb 95 22:51:04 PST Date: Thu, 9 Feb 1995 22:51:03 -0800 (PST) From: Gregory Glen Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Re: Idea for movie 1 In-Reply-To: <199502100641.WAA22134@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > After re-reading the plot, a question immediately came to mind: the probes > were launched three years ago...so why are they only now starting to attacK? Martijn wrote it, and he's absent for a bit...so I'll infer some ideas... I think that since these probes are so quick to change completely, that the independance of original programming is a recent mutation...and so they pretty suddenly attack. It also mentions that the humans send a bunch of conventional ships to hash them up...this might provote a large attack on earth...you (the player) of course are the last hope...blah blah > Perhaps in movie 1, this could be stated. Also, what if the player were > given a ship that was supposed to imitate the probes after all of the > obviously-human-built ships were trashed, to make the probes not constantly > attack the player? Breeding could be added in after round 1 (the aliens This sounds pretty behaviour-like. Run it by the Alifers and see if they like the idea of introducing more hostility towards the player for each band of space entered...it would definitely help game-play. > on the first round will be wimps anyway) as an improvement gained by > observing the aliens...more improvements would require captured aliens/ > alprobes. > You mean no player-fertilization on the first round? Sounds fair...the aliens will be pretty weak and clued out as it is...once they have some time to evolve (by the second round) then give the player fertilization power.... I'm not sure though....comments from the rest of us? -=GT=- From ???@??? Fri Feb 10 10:24:16 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id KAA09976 for ; Fri, 10 Feb 1995 10:14:42 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rcx5Q-000fIyC; Fri, 10 Feb 95 07:16 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/30Dec94-1225PM) id AA28342; Fri, 10 Feb 1995 07:14:47 -0800 From: Charles Ofria Message-Id: <9502101514.AA28342@altair.krl.caltech.edu> Subject: Re: Idea for movie 1 To: ag-directors@alnilam.krl.caltech.edu Date: Fri, 10 Feb 1995 07:14:47 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2148 -- By: Gregory Glen Taylor > Martijn wrote it, and he's absent for a bit...so I'll infer some ideas... > > I think that since these probes are so quick to change completely, that > the independance of original programming is a recent mutation...and so > they pretty suddenly attack. It also mentions that the humans send a > bunch of conventional ships to hash them up...this might provote a large > attack on earth...you (the player) of course are the last hope...blah blah I could easily see the almost the entire human fleet being wiped, but one alien captured and as a last ditch effort it was re-built into a ship of sorts. Since a good amount of evolution has gone by before you (the player) can get back there, it takes a turn for you to become compatable again. > This sounds pretty behaviour-like. Run it by the Alifers and see if they > like the idea of introducing more hostility towards the player for each > band of space entered...it would definitely help game-play. Its fairly easy to do - simply make the humans worth more and more energy to the aliens each passing round. Thus it would naturally be worth more for the aliens to kill them. > > on the first round will be wimps anyway) as an improvement gained by > > observing the aliens...more improvements would require captured aliens/ > > alprobes. I'm not sure I agree with the part about the aliens starting out as wimps; I think they will start out with genrally good code, and as the game goes on they will simply learn more about their environment and the specific weaknesses of the player. > You mean no player-fertilization on the first round? Sounds fair...the > aliens will be pretty weak and clued out as it is...once they have some > time to evolve (by the second round) then give the player fertilization > power.... I'm not sure though....comments from the rest of us? > > -=GT=- Clued out - yes; weak - no. I think I might also be picturing rounds to be much shorter than you guys are. It's not that relevant (things will work either way), but how long (say in player completetion time) do you picture each round to be? --- Charles From ???@??? Fri Feb 10 13:07:30 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA07689 for ; Fri, 10 Feb 1995 12:52:55 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rczYS-000fIvC; Fri, 10 Feb 95 09:54 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id JAA27598 for ag-directors@alnilam.krl.caltech.edu; Fri, 10 Feb 1995 09:52:54 -0800 Date: Fri, 10 Feb 1995 09:52:54 -0800 From: Adrian Tymes Message-Id: <199502101752.JAA27598@mcl.mcl.ucsb.edu> To: ag-directors@alnilam.krl.caltech.edu Subject: Plot After thinking about the idea last night, I came up with a possible plotline: After the 3rd (maybe 4th) band is cleared, as the player is communicating with other human forces (probably the people studying the stuff that the player's captured so far), someone taps in to the communications. After a bit of confusion, it is revealed that the probes are trying to communicate. Inital attempts only appear to make them angry (end of one movie, others try to re-establish contact while the player fights, then in the next movie...) , ; eventually it is revealed that some humans started the fight (they trashed some probes, which initiated retaliatory self-defense, including the destruction of the mining outpost). After a while, some of the probes say they want peace, and ask the player to destroy their stronger probes (who cann not conceive of peace, and wouldn't want it if they could). The end would show the establishing of peaceful co-existence between the remaining probes and humanity...assuming the player won, of course. (I know the probes weren't sentient when they were created, but these probes evolve a *lot* faster than "natural" life does...) Comments? From ???@??? Fri Feb 10 16:09:01 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id PAA09621 for ; Fri, 10 Feb 1995 15:54:28 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rd2OG-000fIvC; Fri, 10 Feb 95 12:56 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA25239; Fri, 10 Feb 95 12:56:03 PST Date: Fri, 10 Feb 1995 12:56:02 -0800 (PST) From: Gregory Glen Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Re: Plot In-Reply-To: <199502101752.JAA27598@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I like the idea. Without it our movies will lack much girth, ("movie 5, another film of your probe blasting the pther probes...joy!")...We've got 8 movies to show the plot, so we could use a dynamic plot...good work Adrian. Anyone want to write the script for the movies? I suppose that belongs in the Art-Sound group...but I figure one of you might like to try it... Thoughts? -=GT=- From ???@??? Fri Feb 10 22:03:49 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id VAA03784 for ; Fri, 10 Feb 1995 21:47:00 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rd7u6-000fIvC; Fri, 10 Feb 95 18:49 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id SAA15458 for ag-directors@alnilam.krl.caltech.edu; Fri, 10 Feb 1995 18:47:49 -0800 Date: Fri, 10 Feb 1995 18:47:49 -0800 From: Adrian Tymes Message-Id: <199502110247.SAA15458@mcl.mcl.ucsb.edu> To: ag-directors@alnilam.krl.caltech.edu Subject: Plot script I would be willing to help write the script. I've already got part of it imagined (Y=player, S=head scientist studying the alien debris resulting from the player's activities, P=probe that's contacting the humans): Y: But who created the probes? Whoever it is must know something about the mailx: deleted 1 NULL character in mail file probes... S: *I* created them. Why do you think I'm helping you get rid of them? P: Impossible. God created us. S: Really? Then I'm god. And god says stop trashing the humans! From ???@??? Sat Feb 11 02:13:09 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id CAA28505 for ; Sat, 11 Feb 1995 02:04:33 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rdBvK-000fIvC; Fri, 10 Feb 95 23:07 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id XAA18890; Fri, 10 Feb 1995 23:05:18 -0800 From: Adrian Tymes Message-Id: <199502110705.XAA18890@mcl.mcl.ucsb.edu> Subject: main.c rev 0.02 (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Fri, 10 Feb 1995 23:05:18 -0800 (PST) Cc: ag-universe@alnilam.krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4537 /***************************************************************************\ * Alife Game - main.c code file * *---------------------------------------------------------------------------* * Copyright (C) 1994 Us. All Rights Reserved. * *---------------------------------------------------------------------------* * Created by: Adrian Tymes * * Last Revised: February, 1995 * * By: Adrian Tymes * * Version #: 0.022 * \***************************************************************************/ // IGNORE 0.021. There were some bugs in it; I think I've caught them here. #define NEW_ULX 220 #define NEW_ULY 221 #define NEW_LRX 502 #define NEW_LRY 301 // "New Game" button boundaries on 0-1023,0-1023 screen #define LOAD_ULX 220 #define LOAD_ULY 308 #define LOAD_LRX 502 #define LOAD_LRY 388 // "Load Game" button boundaries on 0-1023,0-1023 screen #define SAVE_ULX 521 #define SAVE_ULY 308 #define SAVE_LRX 803 #define SAVE_LRY 388 // "Save Game" button boundaries on 0-1023,0-1023 screen // this button is disabled unless the game is paused #define CONT_ULX 521 #define CONT_ULY 221 #define CONT_LRX 803 #define CONT_LRY 301 // "Continue Game" button boundaries on 0-1023,0-1023 screen // this button is disabled unless the game is paused #define REP_ULX 220 #define REP_ULY 395 #define REP_LRX 803 #define REP_LRY 475 // "Replay Movie" button boundaries on 0-1023,0-1023 screen // this button becomes "Show Background Story" when game is not paused #define INST_ULX 220 #define INST_ULY 482 #define INST_LRX 803 #define INST_LRY 562 // "Instructions" button boundaries on 0-1023,0-1023 screen #define OPT_ULX 220 #define OPT_ULY 568 #define OPT_LRX 803 #define OPT_LRY 648 // "Options" button boundaries on 0-1023,0-1023 screen #define CRED_ULX 220 #define CRED_ULY 655 #define CRED_LRX 803 #define CRED_LRY 735 // "Credits" button boundaries on 0-1023,0-1023 screen #define QUIT_ULX 220 #define QUIT_ULY 743 #define QUIT_LRX 803 #define QUIT_LRY 823 // "Quit" button boundaries on 0-1023,0-1023 screen #define UN_Within(x,y,a,b,c,d) ((x>a)&&(xb)&&(y; Sat, 11 Feb 1995 15:29:30 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rdOUx-000fIvC; Sat, 11 Feb 95 12:32 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id PAA19764 for ; Sat, 11 Feb 1995 15:28:56 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 11 Feb 1995 15:35:46 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: main.c rev 0.02 (fwd) Ok...I've got one complaint with this, that I should've brought up back when the .011 came out. This code seems to be rather pc-oriented. You're doing a lot of work that the mac system takes care of. All those defines would be in a resource file. All buttons would be handled by the system..I think that the FE should be determining what button was hit, or even have a FE_GetMenuSelection... Also, the screen size here (1024x1024) is unheard of on a Mac...I've got a 'high' resolution monitor,and it's only 832x624, most are 640x480. Also, there's only one button on the Macintosh mouse. I realize that only one is being used here, but I wanted to make sure you know, as the FE_MouseButtons checks for two buttons... Other than that....nice work, Adrian. Later... --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Sat Feb 11 17:50:54 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id RAA06222 for ; Sat, 11 Feb 1995 17:42:45 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rdQYX-000fIvC; Sat, 11 Feb 95 14:44 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id OAA05757; Sat, 11 Feb 1995 14:42:47 -0800 From: Adrian Tymes Message-Id: <199502112242.OAA05757@mcl.mcl.ucsb.edu> Subject: universe.c rev 0.011 (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Sat, 11 Feb 1995 14:42:47 -0800 (PST) Cc: ag-universe@alnilam.krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2739 /***************************************************************************\ * Alife Game - universe.c code file * *---------------------------------------------------------------------------* * Copyright (C) 1994 Us. All Rights Reserved. * *---------------------------------------------------------------------------* * Created by: Adrian Tymes * * Last Revised: February, 1995 * * By: Adrian Tymes * * Version #: 0.021 * \***************************************************************************/ #define syskeys objects[0]->action.time // player is the first object, and the time field of its action is the syskeys short curobj; // object # current being checked, as in objects[curobj] char probesalive; // Boolean: are there any probes left alive? // set to 1 by UN_CheckObject if it checks any probes char UN_NewSector() { // starts a new sector, shows the appropriate movie, returns 1 if the // final wave has just been cleared, otherwise 0 } void UN_InitGame() { // I think I'll wait on completing this until UN_UpdateObject is written } void UN_DoQueue() { // UN_UpdateObject will put things that need to be done when CPU time is // available (generate aliens, mainly) on a queue, each call to UN_DoQueue // will do the first thing on the queue } void UN_UpdateObject() { // updates objects[curobj] // This is where collision detection & resolution will occur...directors, // would it be ok for me to release the object and genotype specifications // (thus far) to the universe group so someone else can write this? One of // the universe coders says he has functional code for collision detection, // presumably he'd just need to know what variables & functions to call in // order to copy his code here. } void UN_NewLife() { // This will also wait for UN_UpdateObject()... } short UN_PlayGame() { // Will be called when a sector has been started, either by UN_NewSector() // or by a game having been paused in mid-sector, then unpaused short lasticks=FE_Update(); while (1) { aliensalive=0; for (curobj=0;curobj0) UN_UpdateObject(); while (ticksper>FE_GetTicks(lasticks)) UN_DoQueue(); lasticks=FE_Update(); // syskeys that aren't handled below handled here if ((syskeys)&4) FE_ToggleSound(); if ((syskeys)&2) return 2; if ((objects->life)<=0) UN_NewLife(); // sets go to 1 if no lives left for the player if ((syskeys)&1) return MA_ConfirmQuit(go); if (probesalive) if (UN_NewSector()) return 1; }} From ???@??? Mon Feb 13 13:55:05 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA18348 for ; Mon, 13 Feb 1995 13:45:30 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0re55C-000fIyC; Mon, 13 Feb 95 10:01 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id JAA20755 for ag-directors@alnilam.krl.caltech.edu; Mon, 13 Feb 1995 09:59:00 -0800 From: Adrian Tymes Message-Id: <199502131759.JAA20755@mcl.mcl.ucsb.edu> Subject: Bitmap mask check To: ag-directors@alnilam.krl.caltech.edu Date: Mon, 13 Feb 1995 09:58:59 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 333 One thing that the universe group is considering for collision detection is ANDing two bit masks together if two objects have overlapping bounding boxes. This will take a lot of CPU time, I suspect, so we may want to write this in assembly (or do the FE coders think it will run just as fast if compiled from C). Suggestions? From ???@??? Mon Feb 13 17:23:54 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id QAA17850 for ; Mon, 13 Feb 1995 16:28:03 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0re8MB-000fIvC; Mon, 13 Feb 95 13:30 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id QAA17579 for ; Mon, 13 Feb 1995 16:26:35 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Feb 1995 16:33:40 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: main.c rev 0.02 (fwd) >> who decided this? you said that you had previously agreed that it should >> be FE, but that the FE had said "no" why did that FE alone make the >> decision? >> >It's all in the interest of portability. We want the Universe and Alife >code chunks to contain as much code as possible, for they will be written >to be portable. The routines that -must- be machine specific are done by >the FE groups. Thus the menu's are drawn by the Art/Sound group, which >will be standard for all of the formats. Each format will then scale >that image (640x480x24bit) down to their particular size/colornum. The >universe will control the inner workings of the menus, by calling FE >routines to display the menu and to get the input from the user. This >way the FE's don't have to code all of the menus, they simply have to >code the routines which will return the proper data to the universe. ok...I just didn't recall any discussion of this..but it's fine... >Why Adrian chose a 1024x1024 coordinate system (i've never heard of >anything like it) to be the standard values I really can't tell. A >better choice would be 640x480 with is the maximum resolution we are >supporting...but either way will work... Well, I like the 1024x1024, because my monitor is 832x624...his idea was that the FE would just scale down everything, which is fine, but the art/sound people should (obviously) be told about it... --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Mon Feb 13 18:04:50 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id RAA03152 for ; Mon, 13 Feb 1995 17:49:50 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0re9d2-000fIvC; Mon, 13 Feb 95 14:52 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA13502; Mon, 13 Feb 95 14:51:42 PST Date: Mon, 13 Feb 1995 14:51:40 -0800 (PST) From: Gregory Glen Taylor To: Directors Subject: Biz discussion Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII =-=-=-=-=-=-=-=-=-=- - Biz Discussion = =-=-=-=-=-=-=-=-=-=- Ok guys, it's coming down to the critical point in the project when legal matters are in dire need of discussion and decision. We need to get an official structure set up within our ranks before major group coding/work can begin (work being all non-coded data). I've got a few ideas, but am by no means a legal expert (barely a novice)...but I'll try to start this discussion with a few of my ideas. ---------------------- - US - The company - ---------------------- So far I've been joking a bit in the files by claiming copyright by 'Us' rather than listing all of our names, etc. But the 'US' aspect will have to be soon a company name...and that company is one we will make. I have discussed this topic with a few people in the legal end of programming and they suggested that we form a company, which is directed by one of us (the directors) who would set it up and manage the legal jargon etc. The other directors will be a part of the 'company' as 'employees'. This mass of us (what...about 7 or so) will make group decisions about policy etc (hopefully giving a fairer governing of the business). The remaining people on the project (those in the groups) will be signed on as 'contractors' to the company. They would sign a form of some sort (we'd have to make one up, most likely with the assistance of a lawyer)...which would fill in all of the legal restrictions/etc. So in short, anyone with director access to Mike's computer would form the company...all those which member access would form the contractors. ------------------------- - Profit Distribution - ------------------------- With a legal entity and the forms signed, the profit distribution will be legally decidable by the company (directors). We would (together) decide upon a reasonable and fair way to classify people into profit categories. These would be derived from various criterium : How much work they put out (Est # of hours to preform that work is the measure, not just lines of code/#of pictures/#of musical scores), as well as compensation for administrative non-tangible work (thus making the directors get a bit more, just because we do more). We lay out a few profit catagories, something like : (1) Directors/major contributers (2) contributers (3) minor contributers. ---------------- - Production - ---------------- We're going to have to find a producer for the game once it has reached it's 'Beta' stage...this shouldn't be too hard (it'll be a good game :) but in order to do so we will need a company of our own to deal with the terms etc. Thus it is imperitive that we form a company for this and the above reasons. --------------------------- - But who'll manage it? - --------------------------- The header speaks for itself...one or more of us will, but who has the know-how/ability to do it? --------------------- - A Biz Sub-group - --------------------- For those of you who might be thinking, "why don't we set up a 'biz' sub-group to handle all of this stuff.", I've got an early answer : this -is- that group...as directors it's our responsibility to figure this aspect of the project out... so let's do it... The debate it up...what's your ideas? -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Mon Feb 13 18:04:52 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id RAA03231 for ; Mon, 13 Feb 1995 17:50:27 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0re9eV-000fIyC; Mon, 13 Feb 95 14:53 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA13762; Mon, 13 Feb 95 14:53:10 PST Date: Mon, 13 Feb 1995 14:53:08 -0800 (PST) From: Gregory Glen Taylor To: Z Directors Subject: Marc Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Marc Hernandes has expressed a desire to be on the directors list. I just thought I'd ask if anyone has any objections to adding him to the list... -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Mon Feb 13 19:01:50 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA08835 for ; Mon, 13 Feb 1995 18:20:52 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reA7m-000fIvC; Mon, 13 Feb 95 15:24 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id PAA07328 for ag-directors@alnilam.krl.caltech.edu; Mon, 13 Feb 1995 15:22:00 -0800 From: Adrian Tymes Message-Id: <199502132322.PAA07328@mcl.mcl.ucsb.edu> Subject: Re: main.c rev 0.02 (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Mon, 13 Feb 1995 15:22:00 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1369 > >Why Adrian chose a 1024x1024 coordinate system (i've never heard of > >anything like it) to be the standard values I really can't tell. A > >better choice would be 640x480 with is the maximum resolution we are > >supporting...but either way will work... > > Well, I like the 1024x1024, because my monitor is 832x624...his idea was > that the FE would just scale down everything, which is fine, but the > art/sound people should (obviously) be told about it... Actually, I didn't come up with 1024x1024. That number, and the "virtual screen" idea (scaling everything to fit the monitor), had already been suggested by the time I started coding main.c 0.011 . If we want to change the dimensions of the virtual screen, now would *definitely* be the time to do it. Whatever dimensions we end up with, the AS people should draw the menu screens to put the buttons at the coordinates in the main.c file. I don't think that the universe.c code will have to worry about the virtual screen, since the entire screen layout (area near player, status readouts, etc.) will be redrawn by the FE code, which will determine the layout of the non-menu screens. BTW, for the sector selection screen (a form of menu), should the universe code rely on the FE_DisplayScreen(SECTORSELECT) function to display which sectors have been conquered and which can be selected? From ???@??? Mon Feb 13 19:04:08 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA14615 for ; Mon, 13 Feb 1995 18:55:27 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reAfG-000fIvC; Mon, 13 Feb 95 15:58 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA14377 for ; Mon, 13 Feb 1995 18:54:38 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Feb 1995 19:01:31 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: main.c rev 0.02 (fwd) >> >> Well, I like the 1024x1024, because my monitor is 832x624...his idea was >> that the FE would just scale down everything, which is fine, but the >> art/sound people should (obviously) be told about it... >> >We decided upon 640x480 as the max res a long time ago...and on larger >screens just have a window contain the 640x480 screen. You might propose >to the directors to up that to a 800x600 or thereabouts...Since all of >the pictures will be raytraced or delveloped through algorhythms the max >res doesn't matter too much (We can scale it around) but we wanted to >pick the largest -realistic- resolution...640x480 is big (and at 24bit >color) there will be not many PCs who support that big of a res. On >mac's it might be small, but then again, speed interests are in play as >well...getting that many pixels to the screen is tough work to do quickly >in 24bit color...when you go larger than 640x480 the drawing routines >will suck up a large ammount of CPU time. It was the highest res that >made sense. > >If you find it feasible to support a larger res at 24bit color, and there >is enough market support for such a res, then propose it to the directors >and let us talk about it. Okay, here's my proposal: :) The established resolution had been 640x480x24...This is a standard resolution on pc's, but not on mac's. The standard has been only 8 or 16 bit color. My monitor, a new/advanced monitor does not support 24 bit, but it can go to 832x624x16. These monitors are becoming more common now(all the freshman here have them, and the same at several colleges that I know of)...So I think that we should change the standard resolution to 1024x1024x24, as it is in the main.c code. This resolution would then be scaled down to the proper size by the front end according to the configuration of the individual computer. For those concerned about speed decreases at the higher resolution, there is only a 12% difference (the decreased depth compensates for the increased area)... So what's everybody have to say? --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Mon Feb 13 19:14:14 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id TAA16178 for ; Mon, 13 Feb 1995 19:03:55 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reAmi-000fIvC; Mon, 13 Feb 95 16:06 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA14386 for ; Mon, 13 Feb 1995 18:54:41 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Feb 1995 19:01:35 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Marc >Marc Hernandes has expressed a desire to be on the directors list. I >just thought I'd ask if anyone has any objections to adding him to the >list... > >-=GT=- If no one else has an objection, I'll go along, but everyone here is here for a reason(ie. in charge of some part of the dev) What function would he serve? --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Mon Feb 13 19:14:17 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id TAA16541 for ; Mon, 13 Feb 1995 19:06:20 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reApd-000fIvC; Mon, 13 Feb 95 16:09 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id BAA13175 for ; Tue, 14 Feb 1995 01:07:16 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id BAA17802 for ag-directors@alnilam.krl.caltech.edu; Tue, 14 Feb 1995 01:07:13 +0100 From: Martijn Faassen Message-Id: <199502140007.BAA17802@laurel.stud.phil.ruu.nl> Subject: Re: Marc To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 14 Feb 1995 01:07:12 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 549 > > >Marc Hernandes has expressed a desire to be on the directors list. I > >just thought I'd ask if anyone has any objections to adding him to the > >list... > > > >-=GT=- > > > If no one else has an objection, I'll go along, but everyone here is here > for a reason(ie. in charge of some part of the dev) What function would he > serve? > The same goes for me. Why be on the directors list? > > --- > Michael Mitchener > st944m5h@post.drexel.edu > Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Feb 13 22:54:00 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id WAA08062 for ; Mon, 13 Feb 1995 22:45:58 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reEGM-000fIvC; Mon, 13 Feb 95 19:49 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA17051; Mon, 13 Feb 95 19:48:36 PST Date: Mon, 13 Feb 1995 19:48:34 -0800 (PST) From: Gregory Glen Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Re: main.c rev 0.02 (fwd) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > >We decided upon 640x480 as the max res a long time ago...and on larger > >screens just have a window contain the 640x480 screen. You might propose > >to the directors to up that to a 800x600 or thereabouts...Since all of > >the pictures will be raytraced or delveloped through algorhythms the max > >res doesn't matter too much (We can scale it around) but we wanted to > >pick the largest -realistic- resolution...640x480 is big (and at 24bit > >color) there will be not many PCs who support that big of a res. On > >mac's it might be small, but then again, speed interests are in play as > >well...getting that many pixels to the screen is tough work to do quickly > >in 24bit color...when you go larger than 640x480 the drawing routines > >will suck up a large ammount of CPU time. It was the highest res that > >made sense. > > > >If you find it feasible to support a larger res at 24bit color, and there > >is enough market support for such a res, then propose it to the directors > >and let us talk about it. > > > Okay, here's my proposal: :) > > The established resolution had been 640x480x24...This is a standard > resolution on pc's, but not on mac's. The standard has been only 8 or 16 > bit color. My monitor, a new/advanced monitor does not support 24 bit, but > it can go to 832x624x16. These monitors are becoming more common now(all > the freshman here have them, and the same at several colleges that I know > of)...So I think that we should change the standard resolution to > 1024x1024x24, as it is in the main.c code. This resolution would then be > scaled down to the proper size by the front end according to the > configuration of the individual computer. For those concerned about speed > decreases at the higher resolution, there is only a 12% difference (the > decreased depth compensates for the increased area)... > > So what's everybody have to say? > 1024x1024 is -bad-. These images will be raytraced and when a 1024x1024 raytrace is scaled to a ... say 800x600 you'll get -noticable- distortion... Whatever the standard size ends up as, should be in the 4:3 ratio or so. Any counterarguements? -=GT=- From ???@??? Mon Feb 13 23:07:47 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id WAA12535 for ; Mon, 13 Feb 1995 22:55:15 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reEPV-000fIvC; Mon, 13 Feb 95 19:58 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA18339; Mon, 13 Feb 95 19:58:03 PST Date: Mon, 13 Feb 1995 19:58:02 -0800 (PST) From: Gregory Glen Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Re: main.c rev 0.02 (fwd) In-Reply-To: <199502132322.PAA07328@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > BTW, for the sector selection screen (a form of menu), should the > universe code rely on the FE_DisplayScreen(SECTORSELECT) function to > display which sectors have been conquered and which can be selected? > Good question.... I'd say have the AS peopl draw up a background picture for this (including any text like "Select a new sector") and then make a few 128x128x24bit squares : One 'uncleared' picture for each sector (these should hint at the 'bands' in apperance), then just leave the sector blank (let the background show thru) for those uncleared sectors. FE would require all of the cleared sector information (16 sectors, stored bitwise in a short int). We will also want to add a 'FE_Box' routine which will draw a box to the standardized coordinate system in the cursor color (usually bright white, color 256 in 8bit, I don't know the value in 16 or 24bit color). This way the Universe code could put a box around the currently "highlighted" sector. Make sense? -=GT=- From ???@??? Tue Feb 14 14:15:51 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA00442 for ; Tue, 14 Feb 1995 14:06:38 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reSdH-000fJ1C; Tue, 14 Feb 95 11:09 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id LAA18735 for ag-directors@alnilam.krl.caltech.edu; Tue, 14 Feb 1995 11:07:45 -0800 From: Adrian Tymes Message-Id: <199502141907.LAA18735@mcl.mcl.ucsb.edu> Subject: Re: main.c rev 0.02 (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Tue, 14 Feb 1995 11:07:45 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 823 > FE would require all of the cleared > sector information (16 sectors, stored bitwise in a short int). Easily added to the next universe.h version, right? > We will also want to add a 'FE_Box' routine which will draw a box to the > standardized coordinate system in the cursor color (usually bright white, > color 256 in 8bit, I don't know the value in 16 or 24bit color). This > way the Universe code could put a box around the currently "highlighted" > sector. Actually, we'd probably want to make three types of boxes: one for possible sectors, one for cleared sectors, and one for not-yet-reachable sectors. Just so we agree on the coordinates for sectors, here's my idea for sector numbering (numbers in sectors are id/band): 0/1 1/2 2/3 3/4 4/2 5/3 6/4 7/5 8/3 9/4 10/5 11/6 12/4 13/5 14/6 15/7 From ???@??? Tue Feb 14 14:56:00 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA08060 for ; Tue, 14 Feb 1995 14:47:38 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reTGp-000fJ1C; Tue, 14 Feb 95 11:50 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id KAA15539 for ag-directors@alnilam.krl.caltech.edu; Tue, 14 Feb 1995 10:58:29 -0800 From: Adrian Tymes Message-Id: <199502141858.KAA15539@mcl.mcl.ucsb.edu> Subject: Re: main.c rev 0.02 (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Tue, 14 Feb 1995 10:58:29 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 722 > 1024x1024 is -bad-. These images will be raytraced and when a 1024x1024 > raytrace is scaled to a ... say 800x600 you'll get -noticable- > distortion... Whatever the standard size ends up as, should be in the 4:3 > ratio or so. Any counterarguements? -=GT=- Remember, 1024x1024 only applies for the screens that the universe has to deal with...and as far as I can tell, these will only be the menus and sector selection screen. During the movies and the game, FE code will have total control over the screen and the universe won't be dealing with it. I don't know if Art/Sound will require a virtual screen, but the menus and sector select screen can be done by something other than raytracing, if needed. From ???@??? Tue Feb 14 15:16:11 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA04842 for ; Tue, 14 Feb 1995 14:30:56 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reT0m-000fJ1C; Tue, 14 Feb 95 11:34 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA21780; Tue, 14 Feb 95 11:33:27 PST Date: Tue, 14 Feb 1995 11:33:25 -0800 (PST) From: Gregory Glen Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Re: main.c rev 0.02 (fwd) In-Reply-To: <199502141907.LAA18735@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > FE would require all of the cleared > > sector information (16 sectors, stored bitwise in a short int). > > Easily added to the next universe.h version, right? > Yes. > > We will also want to add a 'FE_Box' routine which will draw a box to the > > Actually, we'd probably want to make three types of boxes: one for possible > sectors, one for cleared sectors, and one for not-yet-reachable sectors. > Only one is needed...the universe code will put boxes around the possible sectors. Those that have been cleared will have the background showing thru, and those that are yet to be cleared will either have a box around them or no (depending on whether you can select them)...so only one box is needed. > Just so we agree on the coordinates for sectors, here's my idea for sector > numbering (numbers in sectors are id/band): > > 0/1 1/2 2/3 3/4 > 4/2 5/3 6/4 7/5 > 8/3 9/4 10/5 11/6 > 12/4 13/5 14/6 15/7 > looks reasonable. The movies would then be numbered as such : 0 : Intro 1..7 : Band-entrance movies 8 : Finale'...'you win' movie. 9 : Credits movie. That covers all of them right? -=GT=- From ???@??? Tue Feb 14 16:56:15 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id QAA00553 for ; Tue, 14 Feb 1995 16:42:27 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0reV3U-000fIvC; Tue, 14 Feb 95 13:45 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA14584; Tue, 14 Feb 95 13:44:21 PST Date: Tue, 14 Feb 1995 13:44:19 -0800 (PST) From: Gregory Glen Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Max Res. In-Reply-To: <199502141858.KAA15539@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > 1024x1024 is -bad-. These images will be raytraced and when a 1024x1024 > > raytrace is scaled to a ... say 800x600 you'll get -noticable- > > distortion... Whatever the standard size ends up as, should be in the 4:3 > > ratio or so. Any counterarguements? -=GT=- > > Remember, 1024x1024 only applies for the screens that the universe has to > deal with...and as far as I can tell, these will only be the menus and Whether you -pretend- the screen is 1024x1024 or not is not important, what -is- important is the actual maximum resolution. The menus AND the movies will all share the same resolution (maxres) in the AS release. Then these will be scaled to the proper size for the system. FE will supply the scaling factors to get them to the generic coordinate system values (currently 1024x1024, but I suggest a change to match the maxres) We're talking about display distortion here...a 1024x1024 screen on any monitor I've ever seen would produce a very distorted image...the max res should be someplace near a 4:3 ratio (currently it's 640x480, though we're discussing increasing it to a higher res). To clear up any confusion between the actual display max res and the virtual resolution (which is the scaled coordinates that UN deals with), we should set them equal to eachother....so let's forget about 1024x1024 screen dimensions right now, and discuss the max res...the virtual resolution will simply be set to the same res... > sector selection screen. During the movies and the game, FE code will > have total control over the screen and the universe won't be dealing with > it. I don't know if Art/Sound will require a virtual screen, but the > menus and sector select screen can be done by something other than > raytracing, if needed. > I think you're getting confused between the 'Universe' interpretation of screen size (currently a virtual resolution of 1024x1024, which -will- be changed to be the same as the maxres) and the actual screens which will need to be displayed. 1024x1024 is not a pretty dimension on monitors (they're not square...they're rectangular)....so to avoid this confusion see the above P about unifying the two resolution systems into one value. With that done, what should that value be? I vote for 640x480...does anyone have a better resolution in mind for the maximum resolution? (I know mike wanted something near 800x600) -=GT=- From ???@??? Wed Feb 15 23:49:33 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id XAA01191 for ; Wed, 15 Feb 1995 23:37:06 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rey0e-000fIvC; Wed, 15 Feb 95 20:40 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id UAA21484 for ag-directors@alnilam.krl.caltech.edu; Wed, 15 Feb 1995 20:37:50 -0800 From: Adrian Tymes Message-Id: <199502160437.UAA21484@mcl.mcl.ucsb.edu> Subject: UNIVERSE.H - preview - ver 0.02 (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Wed, 15 Feb 1995 20:37:49 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1792 I just noticed a few things that were missing from the universe.h: > typedef struct { // ** GENOTYPE ** - A genotype for objects. > // genotype 0 = player, then there are inanimate things, then food sources, > // then eggs, then projectiles, then aliens, then boss aliens. etc. etc. Universe code will need the lowest genotype number that uses AI (lowest of projectiles, aliens, and anything else that can affect its own course other than the player). > typedef struct { // ** OBJECT ** - The object data structure. > // FE stuff. > char frame; // Current frame of animation. > > // UN stuff. > short genum; // the genotype index of object. > short x, y; // position in space. Position of what? Center, corner? It has been suggested that this be the upper-left corner of the object (upper-left of universe is 0,0). > short velocity; // the velocity in the movement direction. > unsigned char facdir; // the facing direction (0-255) > unsigned char movdir; // the movement direction (0-255) Much, *MUCH* faster to have short velx, vely, and let AI calculate movdir if it needs to (universe will have to calculate from movdir every screen refresh, reverting to velx and vely will eliminate at least two multiplies per object per screen refresh, not counting any additional AI calculation). > short curarm, cureng; // current ammount of armour and life. > > // AI stuff. > short target; // index of object's current target > actions action; // what the object's current move is > > // Alifers! There should be a lot of your stuff here. We will be adding in next/previous pointers for each object's sector lists, right? > } object; From ???@??? Fri Feb 17 01:04:51 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id XAA09231 for ; Thu, 16 Feb 1995 23:10:18 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rfK4v-000fIvC; Thu, 16 Feb 95 20:14 PST Received: by galaxy.csc.calpoly.edu (4.1/SMI-4.1) id AA20307; Thu, 16 Feb 95 20:13:06 PST Date: Thu, 16 Feb 1995 20:13:05 -0800 (PST) From: Gregory Glen Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Gone for a bit. In-Reply-To: <199502160437.UAA21484@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'll be out of town 'till tuesday, keep up the chat. 'bye -=GT=- From ???@??? Sun Feb 19 16:58:49 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id QAA10347 for ; Sun, 19 Feb 1995 16:46:05 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rgJUd-000fIyC; Sun, 19 Feb 95 13:48 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #9) id m0rgJR4-0004KJC; Sun, 19 Feb 95 23:44 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA03775; 19 Feb 95 20:40:48 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 19 Feb 95 14:39:02 +0200 Subject: Account problems Message-ID: <7ee_9502192040@chameleon.alt.za> Organization: Chameleon BBS To: ag-directors@alnilam.krl.caltech.edu I'm sorry about the prolonged silence from my end - I'm having some trouble establishing my new internet account. I'll let you know as soon as I'm on the nets again... I'm itching to get back to working on the project! Cheers G-J --- GoldED 2.40 | FidoNet: Gert-Jan van Rooyen 5:7102/129.15 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Mon Feb 20 18:42:54 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA16187 for ; Mon, 20 Feb 1995 18:26:30 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rghXG-000fJ3C; Mon, 20 Feb 95 15:28 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id AAA21028 for ; Tue, 21 Feb 1995 00:26:48 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id AAA05295 for ag-directors@alnilam.krl.caltech.edu; Tue, 21 Feb 1995 00:26:46 +0100 From: Martijn Faassen Message-Id: <199502202326.AAA05295@laurel.stud.phil.ruu.nl> Subject: frame rate question To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 21 Feb 1995 00:26:46 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 280 On the alife list we've been worrying about CPU requirements for the creatures. What's the frame rate we're aiming at, and how much of the CPU time could be reserved for the alife routines? Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Feb 20 22:51:49 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id VAA10393 for ; Mon, 20 Feb 1995 21:33:30 -0500 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rgkTC-000fIzC; Mon, 20 Feb 95 18:36 PST Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id SAA06400 for ; Mon, 20 Feb 1995 18:34:52 -0800 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.9) id VAA17620; Mon, 20 Feb 1995 21:34:52 -0500 Message-Id: <199502210234.VAA17620@mcl.mcl.ucsb.edu> Subject: frame rate question (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Mon, 20 Feb 1995 18:34:52 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 649 > On the alife list we've been worrying about CPU requirements for the > creatures. What's the frame rate we're aiming at, and how much of the > CPU time could be reserved for the alife routines? I'd say aim for 30 frames per second; but the CPU time this will translate to will vary between computers. See my skeleton universe.c file for a code explanation of how we'll allocate time to the AI routines. BTW, is there any chance that AI could write a routine that would place the things it needs to do when time allows (for instance, generate a new genotype) on a queue, and another one to execute one item on the queue each time it is called? From ???@??? Mon Feb 20 22:51:50 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id VAA11669 for ; Mon, 20 Feb 1995 21:44:31 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rgkdc-000fIzC; Mon, 20 Feb 95 18:47 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id DAA24863 for ; Tue, 21 Feb 1995 03:45:33 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id DAA06042 for ag-directors@alnilam.krl.caltech.edu; Tue, 21 Feb 1995 03:45:31 +0100 From: Martijn Faassen Message-Id: <199502210245.DAA06042@laurel.stud.phil.ruu.nl> Subject: frame rate question (fwd) To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 21 Feb 1995 03:45:30 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1299 Adrian wrote: > > > On the alife list we've been worrying about CPU requirements for the > > creatures. What's the frame rate we're aiming at, and how much of the > > CPU time could be reserved for the alife routines? > > I'd say aim for 30 frames per second; but the CPU time this will translate > to will vary between computers. See my skeleton universe.c file for a > code explanation of how we'll allocate time to the AI routines. BTW, is > there any chance that AI could write a routine that would place the things > it needs to do when time allows (for instance, generate a new genotype) on > a queue, and another one to execute one item on the queue each time it is > called? > > Well, part of the alife code would need to execute each (or every few) frames, that is of course the behaviour code of the aliens. The rest (mutation, generation of new genotypes, etc) could be placed on a queue, I think. The only trouble that might come up is when the execution time needed for a queu item becomes too large, but we should be able to avoid that (we'd need to avoid that anyhow). A queue has the additional advantage that eggs that are fertilized earlier will also hatch earlier, as is needed. :) Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Feb 27 08:02:27 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id AAA00550 for ; Mon, 27 Feb 1995 00:44:34 -0500 Received: from galaxy by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0riyJq-000fIzC; Sun, 26 Feb 95 21:48 PST Received: (from gtaylor@localhost) by galaxy (8.6.10/8.6.10) id VAA05898; Sun, 26 Feb 1995 21:47:29 -0800 Date: Sun, 26 Feb 1995 21:47:29 -0800 (PST) From: Greg Taylor To: Directors Subject: Biz aspects? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hey guys, if we're going to continue this project, we need to get the biz stuff nailed down...the whole shibang is waiting for that to be decided...comments? -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Mon Feb 27 11:12:23 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id LAA24986 for ; Mon, 27 Feb 1995 11:02:29 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rj7wY-000fIzC; Mon, 27 Feb 95 08:05 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id LAA24649 for ; Mon, 27 Feb 1995 11:00:23 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Return-Receipt-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Feb 1995 11:07:43 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Biz aspects? >Hey guys, if we're going to continue this project, we need to get the biz >stuff nailed down...the whole shibang is waiting for that to be >decided...comments? > >-=GT=- The ever-present question...that nobody answers, including me. I haven't because I have no experience or knowledge in this area. Even if your answer will be the same as mine, please answer, so we know for sure that nobody here can handle this end of it.... Later... --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Mon Feb 27 16:11:53 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id QAA21214 for ; Mon, 27 Feb 1995 16:01:12 -0500 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rjC9Z-000fIzC; Mon, 27 Feb 95 12:34 PST Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id MAA04730 for ; Mon, 27 Feb 1995 12:32:15 -0800 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.9) id PAA02059; Mon, 27 Feb 1995 15:32:08 -0500 Message-Id: <199502272032.PAA02059@mcl.mcl.ucsb.edu> Subject: Re: Biz aspects? (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Mon, 27 Feb 1995 12:32:08 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 703 > >Hey guys, if we're going to continue this project, we need to get the biz > >stuff nailed down...the whole shibang is waiting for that to be > >decided...comments? > > The ever-present question...that nobody answers, including me. I haven't > because I have no experience or knowledge in this area. > > Even if your answer will be the same as mine, please answer, so we know for > sure that nobody here can handle this end of it.... If we can't ensure that we'll be paid for this, do we take it as shareware to one of the big distributors (like Apogee and Epic), and trust them to pay us (big trust factor, but if we have no way to enforce payment...), or should we release it all as freeware? From ???@??? Tue Feb 28 20:22:27 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id UAA14716 for ; Tue, 28 Feb 1995 20:00:35 -0500 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rjcCt-000fIyC; Tue, 28 Feb 95 16:23 PST Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id QAA26176 for ; Tue, 28 Feb 1995 16:21:18 -0800 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.9) id TAA18560; Tue, 28 Feb 1995 19:21:21 -0500 Message-Id: <199503010021.TAA18560@mcl.mcl.ucsb.edu> Subject: Target collision resolution To: ag-directors@alnilam.krl.caltech.edu Date: Tue, 28 Feb 1995 16:21:21 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 782 One possibility I just thought of...to allow AI greater freedom to decide and control the probes' behavior, I'm thinking of putting the following in the collision resolution code (obj and this_obj are pointers to two different objects which have just collided): if (obj->target==this_obj) AI_ResolveTarget(obj,this_obj); else if (this_obj->target==obj) AI_ResolveTarget(this_obj,obj); This would handle: picking things up, breeding, and any other "contact" activities that the AI group wants to include. It would also put things to do on the queue for a subsequent call to AI_DoQueue() to handle. AI could also handle "creation" events (laying eggs, dropping things off) directly (except for shooting projectiles, of course). Would this be preferable to the present method? From ???@??? Wed Mar 01 16:45:47 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id QAA06280 for ; Wed, 1 Mar 1995 16:31:59 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rjush-000fJ1C; Wed, 1 Mar 95 12:20 PST Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id VAA11641 for ; Wed, 1 Mar 1995 21:17:22 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id VAA23214 for ag-directors@alnilam.krl.caltech.edu; Wed, 1 Mar 1995 21:17:21 +0100 From: Martijn Faassen Message-Id: <199503012017.VAA23214@laurel.stud.phil.ruu.nl> Subject: Re: Biz aspects? To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Wed, 1 Mar 1995 21:17:20 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 851 > >Hey guys, if we're going to continue this project, we need to get the biz > >stuff nailed down...the whole shibang is waiting for that to be > >decided...comments? > > > >-=GT=- > > > The ever-present question...that nobody answers, including me. I haven't > because I have no experience or knowledge in this area. > > Even if your answer will be the same as mine, please answer, so we know for > sure that nobody here can handle this end of it.... I don't have experience or much knowledge in this area either. I could ask around, but that would be the Dutch situation, I assume? *ponder being a multinational* :) I agree we do need to talk about this pretty urgently, though. > > Later... > > --- > Michael Mitchener > st944m5h@post.drexel.edu > Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Wed Mar 01 16:45:48 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id QAA06332 for ; Wed, 1 Mar 1995 16:32:15 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rjv4M-000fJ2C; Wed, 1 Mar 95 12:32 PST Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id VAA11833 for ; Wed, 1 Mar 1995 21:29:38 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id VAA23238 for ag-directors@alnilam.krl.caltech.edu; Wed, 1 Mar 1995 21:29:36 +0100 From: Martijn Faassen Message-Id: <199503012029.VAA23238@laurel.stud.phil.ruu.nl> Subject: Re: Target collision resolution To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Wed, 1 Mar 1995 21:29:36 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2280 Adrian Tymes wrote: > One possibility I just thought of...to allow AI greater freedom to decide > and control the probes' behavior, I'm thinking of putting the following > in the collision resolution code (obj and this_obj are pointers to > two different objects which have just collided): > > if (obj->target==this_obj) > AI_ResolveTarget(obj,this_obj); > else if (this_obj->target==obj) > AI_ResolveTarget(this_obj,obj); > > This would handle: picking things up, breeding, and any other "contact" > activities that the AI group wants to include. It would also put things > to do on the queue for a subsequent call to AI_DoQueue() to handle. Well, basically the Alife system is conceived to work like this: Universe calls 'alife' each 'frame' (or whatever time period we measure this in). Then, alife updates all the probes, sending possible keypress outputs to some buffer that Universe reads and executes whenever it reads that. The probes perceive the world actively, they don't usually react to things happening in Universe directly, only when they see them happen. They look around all by themselves, each probe for itself (of course calling some standard routines, and after some preprocessing, but this is the basic idea). So, if some probes evolved or are preprogrammed by the alife team to check for collision events once every few frames, they would react to them. If not, they're probably dumb, or it's more efficient to do other things. What we might implement however, if this would be more efficient, is some list of 'objects recently collided with' or whatever, for each probe, or perhaps a direction to which gene should be more active in case of collision events. So, perhaps it's good to call alife anyway, but not the update probe part, but some perception routine (which we are in the process of designing). > AI could also handle "creation" events (laying eggs, dropping things off) > directly (except for shooting projectiles, of course). I'm not sure what you mean by this? Can you elaborate? > Would this be preferable to the present method? > I think something like this would be handy, thank you for notifying us. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Thu Mar 02 15:47:04 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id PAA18569 for ; Thu, 2 Mar 1995 15:32:53 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rkHcE-000fIyC; Thu, 2 Mar 95 12:36 PST Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id VAA08249 for ; Thu, 2 Mar 1995 21:34:04 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id VAA27245 for ag-directors@alnilam.krl.caltech.edu; Thu, 2 Mar 1995 21:34:01 +0100 From: Martijn Faassen Message-Id: <199503022034.VAA27245@laurel.stud.phil.ruu.nl> Subject: Philosophy To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 2 Mar 1995 21:34:00 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2072 Hello there, Just some random game design philosophy thoughts. It looks like our game will have the interesting feature of being fun at many levels. That is, you can just play it as a shoot 'm up arcade game with a twist. (and it should be good in this respect, good gameplay) You can also use it in god-mode, messing with things like costs of certain investments (what'll happen if I make energy expensive but armour very cheap? what if I drop 20 red critters here?), and waging certain types of probes against each other, altering variables of probes you like or hate (like, changing the energy level, or something, to help them or discourage them). This should be about the level one plays simearth on, or simcity, or simlife. Sim type of games. And then there is the 'guru-mode'. I intend on building in a genetic code editor (this might actually be a rather simple point&click interface, we don't have that many instructions), and I've also been thinking, very prematurely, on including a section in the manual (hereby I volunteer for the manual creation group :) on how to code a good, or interesting probe. Or edit an existing one, if you can make sense of the code evolution produced. This'll enable players to exchange their designer critters, to see who'll win, or to play against your own critters, or to let them evolve and see what happens. Perhaps it wouldn't be too hard to create a 'level designer' for this all. It'll be somewhat equivalent to what the WAD file DOOM people do, or what happens in Corewars. The interesting thing is that grasping the basic arcade level of this game is very easy, and when you want to know more, or play with it more, later, you can do so. I think this would increase the popularity of this game. (though *only* if the basic game engine it good..it shouldn't be *only* fun for the guru types, it should be fun on the arcade level too). Anyway, so far for the design philosophy rambling, back to whatever we were working on. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Thu Mar 02 18:49:29 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id SAA14542 for ; Thu, 2 Mar 1995 18:40:56 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rkKY9-000fIyC; Thu, 2 Mar 95 15:44 PST Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.10/8.6.10) id PAA14443; Thu, 2 Mar 1995 15:43:38 -0800 Date: Thu, 2 Mar 1995 15:43:37 -0800 (PST) From: Greg Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Biz... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > > > The ever-present question...that nobody answers, including me. I haven't > > because I have no experience or knowledge in this area. > > > > Even if your answer will be the same as mine, please answer, so we know for > > sure that nobody here can handle this end of it.... > > I don't have experience or much knowledge in this area either. I could > ask around, but that would be the Dutch situation, I assume? *ponder being > a multinational* :) > > I agree we do need to talk about this pretty urgently, though. > I don't have the time/knowledge to manage such endevours..And there seems to be a lack of volunteering, so what should we do? -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Thu Mar 02 23:42:36 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id TAA25122 for ; Thu, 2 Mar 1995 19:39:06 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rkLSN-000fIyC; Thu, 2 Mar 95 16:42 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/30Dec94-1225PM) id AA20194; Thu, 2 Mar 1995 16:40:10 -0800 From: Charles Ofria Message-Id: <9503030040.AA20194@altair.krl.caltech.edu> Subject: Re: Biz... To: ag-directors@alnilam.krl.caltech.edu Date: Thu, 2 Mar 1995 16:40:10 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 380 -- By: Greg Taylor > I don't have the time/knowledge to manage such endevours..And there seems > to be a lack of volunteering, so what should we do? -=GT=- I guess freeware it is, unless someone gets a sudden interest in running it. Our remaining option is to talk to the non-directors in the project and open up a new director position "buisness director". --- Charles From ???@??? Thu Mar 02 23:42:38 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id TAA26811 for ; Thu, 2 Mar 1995 19:46:29 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rkLZV-000fIyC; Thu, 2 Mar 95 16:50 PST Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.10/8.6.10) id QAA24925; Thu, 2 Mar 1995 16:49:02 -0800 Date: Thu, 2 Mar 1995 16:49:01 -0800 (PST) From: Greg Taylor To: ag-directors@alnilam.krl.caltech.edu Subject: Re: Biz... In-Reply-To: <9503030040.AA20194@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 2 Mar 1995, Charles Ofria wrote: > -- By: Greg Taylor > > I don't have the time/knowledge to manage such endevours..And there seems > > to be a lack of volunteering, so what should we do? -=GT=- > > I guess freeware it is, unless someone gets a sudden interest in running > it. Our remaining option is to talk to the non-directors in the project > and open up a new director position "buisness director". > I vote for trying for a biz director first...-=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Thu Mar 02 23:42:39 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id WAA00219 for ; Thu, 2 Mar 1995 22:07:38 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rkNmD-000fIyC; Thu, 2 Mar 95 19:11 PST Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id EAA12127 for ; Fri, 3 Mar 1995 04:08:45 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id EAA28366 for ag-directors@alnilam.krl.caltech.edu; Fri, 3 Mar 1995 04:08:43 +0100 From: Martijn Faassen Message-Id: <199503030308.EAA28366@laurel.stud.phil.ruu.nl> Subject: Re: Biz... To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Fri, 3 Mar 1995 04:08:42 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 935 Greg Taylor wrote: > On Thu, 2 Mar 1995, Charles Ofria wrote: > > > -- By: Greg Taylor > > > I don't have the time/knowledge to manage such endevours..And there seems > > > to be a lack of volunteering, so what should we do? -=GT=- > > > > I guess freeware it is, unless someone gets a sudden interest in running > > it. Our remaining option is to talk to the non-directors in the project > > and open up a new director position "buisness director". > > > I vote for trying for a biz director first...-=GT=- I agree. And even if we find no solution, we could always try to share the job, or something? I'd volunteer, I guess. :) It just depends on what we plan on producing, if we go for commercial, it ought to be good. (and it should be good when it's freeware too, but there's not so much pressure :) Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Sun Mar 05 12:01:53 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id LAA05055 for ; Sun, 5 Mar 1995 11:47:23 -0500 Received: from gate.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rlJPu-000fIyC; Sun, 5 Mar 95 08:44 PST Received: from darkin.demon.co.uk by gate.gate.demon.co.uk id aa19449; 5 Mar 95 16:35 GMT Received: by darkin.demon.co.uk (V1.16/Amiga) id AA002p9; Sun, 5 Mar 95 14:37:58 GMT Date: Sun, 5 Mar 95 14:37:58 GMT Message-Id: <9503051437.AA002p8@darkin.demon.co.uk> In-Reply-To: (from Greg Taylor ) (at Fri, 3 Mar 1995 14:44:44 -0800 (PST)) X-Mailer: //\\miga Electronic Mail (AmiElm 1.19) Reply-To: christian@darkin.demon.co.uk MIME-Version: 1.0 Content-Type: text/plain From: Christian Darkin To: ag-directors@alnilam.krl.caltech.edu Subject: Re: BIZ Director. Hi Greg, > > A discussion has been going on on the directors group for some time about > the business aspects of the game. The net result is that we feel the > need for a director/group who will specifically handle and manage the > business and legal matters of taking this project into the commercial > realm. > > So what we're talking about doing is at minimum forming a new position of > 'biz director' and perhaps even the 'biz' sub-group to handle such things. > > If any of you have the experience/know-how/time and what to be the biz > director or be in the biz group, send a message to the directors group > about it (that would be ag-directors@alnilam.krl.caltech.edu) and we'll > see what we can do. I`d certainly be interested in getting into this group. As a computer journalist/writer, I`ve got a little experience about publicity. In the UK I`ve written for computer magazines, and national newspapers like the Financial Times and the Guardian, and also I`ve done reports for BBC Radio, and I`m currently getting into doing a little TV work (possibly with Discovery) so I know what the press are interested in, and how to get it to them. I`m not so hot on the computer games industry, but I`m sure I can find out. I suppose the most important thing is to realise that somewhere allong the line, we`re going to have to admit that we can`t handle this alone. The video game market is very much like the rock industry. Little independent groups just don`t make it without sponsorship from the big guys. We can`t hope to produce huge publicity drives or fund the production of hundreds of thousands of coppies of our game (that is if we go for the commercial release). We need to get a big name interested. Once we`ve got something to show them, I`m certain we can do that. I`d really like to get into this new group, but we have to remember that this is big league stuff (remember, Sonic the hedgehog made more money than Jurassic Park). I must say that I`m firmly on the side of doing a commercial release if we can - it will get our game the kind of distribution it needs - but if it`s only for the sake of the science aspect, we need to keep firm control for ourselves. -------------------------------------------------------------------------. !Email christian@darkin.demon.co.uk !Mail Sent Via Demon Internet Services ! !Full Internet Conection For £10/Month Fixed. Tel: 081 349 0063 ! `-------------------------------------------------------------------------' From ???@??? Tue Mar 07 13:31:05 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id NAA14556 for ; Tue, 7 Mar 1995 13:23:39 -0500 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rm3ww-000fIzC; Tue, 7 Mar 95 10:25 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.10/8.6.10) with ESMTP id TAA14297 for ; Tue, 7 Mar 1995 19:22:27 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id TAA02202 for ag-directors@alnilam.krl.caltech.edu; Tue, 7 Mar 1995 19:22:25 +0100 From: Martijn Faassen Message-Id: <199503071822.TAA02202@laurel.stud.phil.ruu.nl> Subject: Plot To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 7 Mar 1995 19:22:24 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 334 Hello, I'm not on the art/sound list (maybe I should be?), but I'm currently working on a script for the movie part on the game, based on the rough plot I came up with before. If anybody is interested in that? Anyway, I'll post it here soon. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Tue Mar 07 16:10:20 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id PAA12523 for ; Tue, 7 Mar 1995 15:59:37 -0500 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rm6NZ-000fIzC; Tue, 7 Mar 95 13:01 PST Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id MAA22173 for ; Tue, 7 Mar 1995 12:58:08 -0800 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.9) id PAA13621; Tue, 7 Mar 1995 15:58:17 -0500 Message-Id: <199503072058.PAA13621@mcl.mcl.ucsb.edu> Subject: Plot (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Tue, 7 Mar 1995 12:58:17 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 287 > I'm not on the art/sound list (maybe I should be?), but I'm currently > working on a script for the movie part on the game, based on the rough > plot I came up with before. If anybody is interested in that? I was already working on a script...I'll forward what I have so far to you. From ???@??? Wed Mar 08 18:13:58 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id SAA02480 for ; Wed, 8 Mar 1995 18:04:05 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rmUmB-000fIzC; Wed, 8 Mar 95 15:04 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/30Dec94-1225PM) id AA28279; Wed, 8 Mar 1995 15:01:06 -0800 From: Charles Ofria Message-Id: <9503082301.AA28279@altair.krl.caltech.edu> Subject: Biz Director Choice? To: ag-directors@alnilam.krl.caltech.edu Date: Wed, 8 Mar 1995 15:01:06 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 290 Greetings, So, it looks like Christian is the only one really interested in the Biz director position, and he sounds like a fine choice to me. If there are no objectections, I propose that we give him the job and move on from there to decide what we are going to do. --- Charles From ???@??? Wed Mar 08 18:23:55 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id SAA03878 for ; Wed, 8 Mar 1995 18:10:47 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rmUui-000fIyC; Wed, 8 Mar 95 15:13 PST Received: from [144.118.44.96] ([144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id SAA03708 for ; Wed, 8 Mar 1995 18:09:48 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Mar 1995 18:15:24 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Biz Director Choice? >Greetings, > > So, it looks like Christian is the only one really interested in the >Biz director position, and he sounds like a fine choice to me. If there are >no objectections, I propose that we give him the job and move on from there >to decide what we are going to do. > > --- Charles I second this :-) --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Wed Mar 08 18:33:53 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id SAA06322 for ; Wed, 8 Mar 1995 18:23:36 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rmV6X-000fIyC; Wed, 8 Mar 95 15:25 PST Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.10/8.6.10) id PAA07325; Wed, 8 Mar 1995 15:23:44 -0800 Date: Wed, 8 Mar 1995 15:23:43 -0800 (PST) From: Greg Taylor To: Z Directors Subject: Re: Biz Director Choice? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 8 Mar 1995, Michael Mitchener wrote: > >Greetings, > > > > So, it looks like Christian is the only one really interested in the > >Biz director position, and he sounds like a fine choice to me. If there are > >no objectections, I propose that we give him the job and move on from there > >to decide what we are going to do. > > > > --- Charles > > I second this :-) > Ditto. > > --- > Michael Mitchener > st944m5h@post.drexel.edu > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Thu Mar 09 05:21:33 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id FAA23332 for ; Thu, 9 Mar 1995 05:13:33 -0500 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rmfFp-000fIyC; Thu, 9 Mar 95 02:15 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.10/8.6.10) with ESMTP id LAA23894 for ; Thu, 9 Mar 1995 11:12:20 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.10/8.6.10) id LAA09230 for ag-directors@alnilam.krl.caltech.edu; Thu, 9 Mar 1995 11:12:15 +0100 From: Martijn Faassen Message-Id: <199503091012.LAA09230@laurel.stud.phil.ruu.nl> Subject: Re: Biz Director Choice? To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 9 Mar 1995 11:12:14 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1149 > On Wed, 8 Mar 1995, Michael Mitchener wrote: > > > >Greetings, > > > > > > So, it looks like Christian is the only one really interested in the > > >Biz director position, and he sounds like a fine choice to me. If there are > > >no objectections, I propose that we give him the job and move on from there > > >to decide what we are going to do. > > > > > > --- Charles > > > > I second this :-) > > > Ditto. Me as well, although as Greg said, directors group is already in a way the Biz group. (I don't want to lose control of Biz completely..which also means that if Chris needs help, and I can give it, I'll do my best) > > > > --- > > Michael Mitchener > > st944m5h@post.drexel.edu > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = > = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Thu Mar 09 08:31:00 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id IAA03135 for ; Thu, 9 Mar 1995 08:17:25 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rmi78-000fIyC; Thu, 9 Mar 95 05:18 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id IAA02968 for ; Thu, 9 Mar 1995 08:15:30 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Mar 1995 08:21:06 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Biz Director Choice? >Me as well, although as Greg said, directors group is already in a way >the Biz group. (I don't want to lose control of Biz completely..which >also means that if Chris needs help, and I can give it, I'll do my best) > >-- >Martijn Faassen email:faassen@phil.ruu.nl Yeah, I think that all of the directors who can, should help him, and all relevant business discussions should go on in this list. I would also be willing to help out however I can. --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Thu Mar 09 08:31:01 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.10/8.6.4) with SMTP id IAA03809 for ; Thu, 9 Mar 1995 08:24:38 -0500 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rmiF0-000fIyC; Thu, 9 Mar 95 05:26 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.10/8.6.10) with ESMTP id OAA27678 for ; Thu, 9 Mar 1995 14:23:40 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.10/8.6.10) id OAA10380 for ag-directors@alnilam.krl.caltech.edu; Thu, 9 Mar 1995 14:23:36 +0100 From: Martijn Faassen Message-Id: <199503091323.OAA10380@laurel.stud.phil.ruu.nl> Subject: Curious.. To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 9 Mar 1995 14:23:35 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 590 I'm curious.. I'm subscribed to directors, universe, and alife, so I know what's going on there (directors the biz discussion, universe currently not much, probably waiting for the biz decision?, alife very very busy with designing the eternally troublesome probe control language - but, making rapid progress, I hope!).. But, what's going on in art/sound? The front end groups? Is Jeff Lait still out there, I wonder? (haven't heard from him, lately) Can anybody give us a short summary? Thanks! Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Sun Mar 12 17:20:17 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id QAA00551 for ; Sun, 12 Mar 1995 16:47:21 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rnvWQ-000fJ7C; Sun, 12 Mar 95 13:49 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #9) id m0rnvTi-00053lC; Sun, 12 Mar 95 23:47 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA04014; 12 Mar 95 20:40:41 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 12 Mar 95 12:05:00 +0200 Subject: Curious.. Message-ID: <126_9503122040@chameleon.alt.za> Organization: Chameleon BBS To: ag-directors@alnilam.krl.caltech.edu On 09 Mar 95, Martijn.Faassen@phil.ruu.nl wrote: > I'm subscribed to directors, universe, and alife, so I know what's going > on there (directors the biz discussion, universe currently not much, > probably waiting for the biz decision?, alife very very busy with > designing the eternally troublesome probe control language - but, making > rapid progress, I hope!).. > But, what's going on in art/sound? The front end groups? Is Jeff Lait > still out there, I wonder? (haven't heard from him, lately) > Can anybody give us a short summary? Once again I apologise for the silence from my end. I'm still having problems with my university email, and have to do all my email every two weeks or so when I'm at my home pc. Hopefully I'll have full communications again soon. PCX and art/sound have been very quiet... and I haven't heard from Jeff either. As for art/sound, the composing of the music can start as soon as we have a rough idea of the movie scenes and plots. Martijn, can you post that movie plot outline you have? Cheers G-J --- GoldED 2.40 | FidoNet: Gert-Jan van Rooyen 5:7102/129.15 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 or +27-21-461-0140 From ???@??? Mon Mar 13 09:19:40 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id JAA01897 for ; Mon, 13 Mar 1995 09:11:30 -0500 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0roAsZ-000fJ9C; Mon, 13 Mar 95 06:13 PST Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.11/8.6.11) with ESMTP id PAA04229 for ; Mon, 13 Mar 1995 15:10:17 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.11/8.6.11) id PAA29561 for ag-directors@alnilam.krl.caltech.edu; Mon, 13 Mar 1995 15:10:10 +0100 From: Martijn Faassen Message-Id: <199503131410.PAA29561@laurel.stud.phil.ruu.nl> Subject: Plot (was: Curious..) To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 13 Mar 1995 15:10:08 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4226 g-j@chameleon.alt.za (Gert-Jan van Rooyen) wrote: > PCX and art/sound have been very quiet... and I haven't heard from Jeff > either. As for art/sound, the composing of the music can start as soon as we > have a rough idea of the movie scenes and plots. Martijn, can you post that > movie plot outline you have? > > Cheers > G-J > Okay, here is the plot I have so far, it shouldn't need much changes anymore (unless anybody disagrees). Adrian worked out a plot for the rest of the demos, and I'll edit that this week for consistency with the part I have here: Project Von Neumann ------------------- Screen: Fade in to star field, with a few scattered asteroids, far away, slowly moving. Overlayed Text: 2107 AD, Asteroid Belt, Sol System Screen: Slow pan down. Should last a few seconds. At the bottom a space fighter comes in sight, closer and closer, then pulling up, and shooting through the screen to the top, and out of sight, all very fast. A few plasma bolts flit behind it, then another space fighter (that fired the bolts) shoots up through the screen, just as fast as the first one, but the frame freezes when it's in the middle of the screen. Overlayed Text: The Belt Habitats struggle for independence from the Earth/Moon United Nations, and thought to gain it by threatening Earth with an asteroid bombardment. The EMUN reacts by sending a strike force to the Asteroid Belt, to 'pacify' the Belters. The Solar War has begun. Screen: Fade out. Fade in to large engineering hall. The huge shape of Von Neumann Probe dominates the view, half finished, with people dwarfed by its size working on it. Torchlight glows, sparks fly, giving the impression of feverish activity. Overlayed Text: 2109 AD, secret EMUN base somewhere in Mare on the Moon. The Solar War is still raging, taking a toll of millions, and no end is in sight. EMUN starts the secret project 'Von Neumann', an attempt to create an invincible fleet of self reproducing robotic probes, controlled by EMUN. Screen: Fade out. Fade in to picture of the moon. An small dot appears somewhere on it (in the right mare), grows in size until the finished Von Neumann probe fills the screen. Freeze frame. Overlayed Text: March 8, 2110 AD. The Von Neumann Probe is successfully launched towards the asteroid belt. Able to reproduce, using the raw materials of asteroids, soon there will be many. Equipped with the capacity for mutations, evolution will optimize the probes to the local environment. Screen: Fade to conference table. Men and women with serious faces sit gathered around it. Overlayed Text: 2111 AD. Conference Center in Arcadia Habitat, L5 Peace is signed, unexpected by both sides. The Belt Habitats gain indepence, and in exchange EMUN observers will be installed in all Belter military bases. Project Von Neumann is conveniently forgotten about by EMUN officials, and kept secret. Screen: Fade to starfield, a few asteroids in sight. Dominating the view an asteroid with structures (a mining outpost) built on it. The structures are wrecked, half molten, still glowing. Overlayed Text: 2121 AD. Mining Outpost 87 in the Asteroid Belt. 10 years after the end of the Solar War. Unknown attackers leave Mining Outpost 87 a lifeless hulk. Soon after, Military Base A7 and habitat Springtime follow. Investigation ships are sent out to determine the cause. Screen: Fade to starfield, a few asteroids, and *many* distant Probes, swirling, eating asteroid, laying eggs, hatching, shooting at each other. Like a cloud of buzzing insects. Occasionally a probe closerby flits through the screen. The probes vary in shape and color, though some common plan may be recognizable. (this depends on what we'll do exactly to generate the probe sprites, in the game) Overlayed Text: Investigation Ship Tau One sent these pictures back shortly before its destruction. When they reach Earth, project Von Neumann finally comes into the open. The first Von Neumann probe reproduced - unchecked. Evolution went on too long and too far, and the descendants of the first probe are now beyond human control... [more coming up] -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Tue Mar 14 08:11:12 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id HAA02781 for ; Tue, 14 Mar 1995 07:29:50 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0roVlp-000fJMC; Tue, 14 Mar 95 04:32 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56843-1>; Tue, 14 Mar 1995 07:28:34 -0500 Date: Tue, 14 Mar 1995 07:28:24 -0500 From: Jeff Lait To: Gert-Jan van Rooyen cc: ag-directors@alnilam.krl.caltech.edu Subject: Re: Curious.. In-Reply-To: <126_9503122040@chameleon.alt.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 12 Mar 1995, Gert-Jan van Rooyen wrote: > > On 09 Mar 95, Martijn.Faassen@phil.ruu.nl wrote: > > > I'm subscribed to directors, universe, and alife, so I know what's going > > on there (directors the biz discussion, universe currently not much, > > probably waiting for the biz decision?, alife very very busy with > > designing the eternally troublesome probe control language - but, making > > rapid progress, I hope!).. > > > But, what's going on in art/sound? The front end groups? Is Jeff Lait > > still out there, I wonder? (haven't heard from him, lately) > > Can anybody give us a short summary? > I'm terribly sorry for not managing to get online for the last while, but I have at last got a service in Ottawa so I should be able to stay on line now - I just need to grab the contents of my mail box (Which had overflowed) and get up to date with where we currently stand. - Jeff Lait From ???@??? Fri Mar 17 13:28:03 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id NAA10241 for ; Fri, 17 Mar 1995 13:20:31 -0500 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rpgen-000fJ6C; Fri, 17 Mar 95 10:21 PST Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id KAA24589; Fri, 17 Mar 1995 10:18:04 -0800 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.9) id KAA21529; Fri, 17 Mar 1995 10:18:03 -0800 Message-Id: <199503171818.KAA21529@mcl.mcl.ucsb.edu> Subject: Break To: ag-directors@alnilam.krl.caltech.edu Date: Fri, 17 Mar 1995 10:18:03 -0800 (PST) Cc: ag-universe@alnilam.krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 213 I'll be away from my current e-mail account from 3/22 to 4/2. Universe group: Are any more of you willing to write code? I've only had two people respond to my request for programmers so far (possibly a third). From ???@??? Sat Mar 18 12:47:42 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id MAA26067 for ; Sat, 18 Mar 1995 12:37:15 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rq2TC-000fJBC; Sat, 18 Mar 95 09:39 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id MAA25776 for ; Sat, 18 Mar 1995 12:35:23 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 18 Mar 1995 12:41:15 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Break >I'll be away from my current e-mail account from 3/22 to 4/2. > >Universe group: Are any more of you willing to write code? I've only had two >people respond to my request for programmers so far (possibly a third). Well...I've tried to respond to this twice, and I've gotten mail delivery errors each time...has anyone else had problems mailing Adrian? --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Sat Mar 18 17:18:37 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id RAA24029 for ; Sat, 18 Mar 1995 17:05:20 -0500 Received: from nic.fonorola.net by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rq6fo-000fIyC; Sat, 18 Mar 95 14:08 PST Received: from [198.53.239.30] by nic.fonorola.net with SMTP (5.65/25-eef) id AA04390; Sat, 18 Mar 95 16:54:00 -0500 Received: by inasec.ca (5.0/SMI-SVR4) id AA10758; Sat, 18 Mar 1995 17:02:05 -0500 Date: Sat, 18 Mar 1995 17:02:03 -0500 (EST) From: Jeff Lait Subject: Life the universe and everything. To: ag-directors@alnilam.krl.caltech.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1723 Hello.. I have finally managed to again get a foot hold in the internet, this time it should last for a while longer (Ottawa freenet SUCKS.) I have reviewed the mail which had hit my mailbox over the last few months, and have only a couple things to ask. - First, just as a note, the 1024x1024 virtual screen was first suggest by myself, and choosen at a whim. On further reflection, a 4:3 ration is definetly a good idea. - Second, Movie formats. The precise compresion which we decide to use will inevitably depend upon the movies which will be used. Also, it depends on what particular system (Mac or PC) which we are writing for (And within those areas, whether we wish 8, 16, or 24 bit colour in the resulting movie. 8 we'd probably have to do dynamic palette alterations, which means either modex or blitting the screen during the vretrace. - Third, what system are we aiming for? IE: How powerful? With the complicated ai routines being mentioned along with SVGA grfx, I would suggest fast VESA with 486. As for the mac end, no idea. Of course, if we include support for 320x200 slower machines also could be included. - Fourth, as for earlier discussions about whether the menuing system should be in the FE area, I believe it was again I who said that these should be kept out of the FE. Remember, the front end code must be rewritten for EVERY system out there. It's designed to take the virtual coordinates and draw boxes/text/whatever. It's not designed to the logic of memory selection. At least, that's how I saw it and continue to see it. - Fifth.. What code still needs to be written for us to have a running game? Or has this already been done? - Jeff Lait (SOL) From ???@??? Sun Mar 19 16:18:16 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id OAA17252 for ; Sun, 19 Mar 1995 14:56:40 -0500 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rqR6f-000fIyC; Sun, 19 Mar 95 11:57 PST Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id LAA03376 for ; Sun, 19 Mar 1995 11:53:50 -0800 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.9) id LAA19513; Sun, 19 Mar 1995 11:53:42 -0800 Message-Id: <199503191953.LAA19513@mcl.mcl.ucsb.edu> Subject: Re: Break (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Sun, 19 Mar 1995 11:53:42 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 495 > >I'll be away from my current e-mail account from 3/22 to 4/2. > > > >Universe group: Are any more of you willing to write code? I've only had two > >people respond to my request for programmers so far (possibly a third). > > Well...I've tried to respond to this twice, and I've gotten mail delivery > errors each time...has anyone else had problems mailing Adrian? What's my address showing up as? uwingcat@something.mcl.ucsb.edu or uwingcat@mcl.ucsb.edu ? If the former, try the latter. From ???@??? Sun Mar 19 16:18:18 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id QAA25583 for ; Sun, 19 Mar 1995 16:12:19 -0500 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rqSIi-000fIyC; Sun, 19 Mar 95 13:14 PST Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id NAA06597 for ; Sun, 19 Mar 1995 13:10:18 -0800 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.9) id NAA02951; Sun, 19 Mar 1995 13:10:15 -0800 Message-Id: <199503192110.NAA02951@mcl.mcl.ucsb.edu> Subject: Life the universe and everything. (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Sun, 19 Mar 1995 13:10:14 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 673 > - First, just as a note, the 1024x1024 virtual screen was first > suggest by myself, and choosen at a whim. On further reflection, a 4:3 > ration is definetly a good idea. Ok, so what are the exact coordinates that we want the virtual screen to be? > - Fifth.. What code still needs to be written for us to have a > running game? Or has this already been done? For the universe code, we'll have a running game when the sector initialization and object <-> AI interface have been coded. There are a few other pieces of universe code that need to be written, but they are not needed for a simple, one-sector, one-player-life game, and thus have lower priority. From ???@??? Sun Mar 19 16:38:23 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id QAA27530 for ; Sun, 19 Mar 1995 16:25:44 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rqSWe-000fIyC; Sun, 19 Mar 95 13:28 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id QAA27419 for ; Sun, 19 Mar 1995 16:24:34 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 19 Mar 1995 16:30:31 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Break (fwd) >> >I'll be away from my current e-mail account from 3/22 to 4/2. >> > >> >Universe group: Are any more of you willing to write code? I've only had two >> >people respond to my request for programmers so far (possibly a third). >> >> Well...I've tried to respond to this twice, and I've gotten mail delivery >> errors each time...has anyone else had problems mailing Adrian? > >What's my address showing up as? uwingcat@something.mcl.ucsb.edu or >uwingcat@mcl.ucsb.edu ? If the former, try the latter. It shows up as which is the address that fails...anyway..since you're obviously getting the list mail, I'll just post here... What I tried to say was that I would code if you need me, but I'm new to C...so use your discretion also, has there been any traffic in the universe list lately? I haven't gotten mail from it in about a month... --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Sun Mar 19 16:38:26 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id QAA27547 for ; Sun, 19 Mar 1995 16:25:56 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rqSWt-000fIzC; Sun, 19 Mar 95 13:28 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id QAA27430 for ; Sun, 19 Mar 1995 16:24:49 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 19 Mar 1995 16:30:45 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Life the universe and everything. (fwd) >> - First, just as a note, the 1024x1024 virtual screen was first >> suggest by myself, and choosen at a whim. On further reflection, a 4:3 >> ration is definetly a good idea. > >Ok, so what are the exact coordinates that we want the virtual screen to >be? We decided that it would be either 640x480 or 832x624...I think that's as far as the discussion got, right? --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Mon Mar 20 08:21:09 1995 Received: from math.uwaterloo.ca (math.uwaterloo.ca [129.97.140.144]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id IAA17215 for ; Mon, 20 Mar 1995 08:06:55 -0500 Received: from nic.fonorola.net ([198.53.64.7]) by math.uwaterloo.ca with SMTP id <78151-3>; Mon, 20 Mar 1995 08:06:53 -0500 Received: from [198.53.239.30] by nic.fonorola.net with SMTP (5.65/25-eef) id AA17431; Mon, 20 Mar 95 07:55:56 -0500 Received: by inasec.ca (5.0/SMI-SVR4) id AA15567; Mon, 20 Mar 1995 08:04:08 -0500 Date: Mon, 20 Mar 1995 08:04:08 -0500 Message-Id: <9503201304.AA15567@inasec.ca> To: ag-directors@alnilam.krl.caltech.edu From: jmlait@cayley.uwaterloo.ca Subject: Aspect ratio Content-Type: text Content-Length: 254 Regarding the proper screen ratios that we should use, I would suggest something larger than 640x480 or 832x624 (Now that's an unusual ratio :>) How bout 1024x768 - that's 4:3 no? The reason why I am suggesting a higher ration is so From ???@??? Wed Mar 22 07:40:07 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id HAA20714 for ; Wed, 22 Mar 1995 07:33:07 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rrPc4-000fIyC; Wed, 22 Mar 95 04:34 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56836-3>; Wed, 22 Mar 1995 07:29:56 -0500 Date: Wed, 22 Mar 1995 07:29:50 -0500 From: Jeff Lait To: ag-directors@alnilam.krl.caltech.edu, ag-pcx@alnilam.krl.caltech.edu Subject: What needs to be done/... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Trouble is, after being gone the last couple months I am unaware of what stage the PCX group has (Or has not) progressed to. I'd also like another couple things verified for the PC platform, stuff hopefully alread dealt with: What compiler will be used with the PC platform? This makes a difference to how the assembly interface is written. I would personally suggest Watcom, compiling for DOS4GW (No sense giving ourselves a silly 64k limit, no?) The reason we need to decide this is because the way the C-assembly interface works differs for every compiler... - Jeff Lait (SOL) From ???@??? Wed Mar 22 09:46:50 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id JAA02477 for ; Wed, 22 Mar 1995 09:34:57 -0500 Received: from oliver.sun.ac.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rrRTP-000fIyC; Wed, 22 Mar 95 06:33 PST Received: from styx.sun.ac.za by oliver.sun.ac.za with smtp (Smail3.1.29.0 #2) id m0rrRO3-0015AjC; Wed, 22 Mar 95 16:27 EET Received: From SUN_FIRGA/WORKQUEUE by styx.sun.ac.za via Charon-4.0A-VROOM with IPX id 100.950322162849.544; 22 Mar 95 16:29:13 -0200 Message-ID: From: "G-J VAN ROOYEN" <9515291@firga.sun.ac.za> Organization: University of Stellenbosch To: ag-directors@alnilam.krl.caltech.edu Date: Wed, 22 Mar 1995 16:28:39 GMT+200 Subject: EMail at last X-Confirm-Reading-To: "G-J VAN ROOYEN" <9515291@firga.sun.ac.za> X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail v3.22 I've finally got my new internet account, after much hassle. Please note that my address has changed from g-j@chameleon.alt.za to 9515291@firga.sun.ac.za . The first address is still valid, I just won't be able to check it so often. So, what's going on around here, and what should start happening when? It'll be nice for me to get to work on the game again :) Cheers G-J +-------------------------------------------------+ | 9515291@firga.sun.ac.za (Gert-Jan van Rooyen) | | University of Stellenbosch | | South Africa | +-------------------------------------------------+ From ???@??? Sun Apr 02 09:53:40 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id RAA17361 for ; Sun, 26 Mar 1995 17:02:17 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rt0RZ-000fIyC; Sun, 26 Mar 95 14:05 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/30Dec94-1225PM) id AA16408; Sun, 26 Mar 1995 14:01:31 -0800 From: Charles Ofria Message-Id: <9503262201.AA16408@altair.krl.caltech.edu> Subject: Important... To: ag-directors@alnilam.krl.caltech.edu Date: Sun, 26 Mar 1995 14:01:31 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1939 Greetings, A problem has recently come to my attention on the legalities of us using our university accounts and equipment for the production of a for-profit product. Any of the universities where people are connecting from could have a reasonable claim towards the end result which would be quite bad for us. Also a number of schools I know of require students to sign forms stating that their accounts will not be used for such purposes (upon thinking about it, I remembered that SUNY Stony Brook - where I went to undergrad) made me sign such a form. At Caltech it boils down to being part of the fact that they own anything produced on their machines. What this boils down to is that unless we only distribute the program as freeware (along with the source code I think) none of us can legaly work on it from university accounts (unless said university owns the rights to it). This includes the mailing lists and ftp site at Caltech unfortunately. I talked to my Sys-admin about this (who confirmed what I stated above) and he is willing to work with us either way we dicide to do things; if we can garentee another site to move every- thing to, we can keep things here long enough to make an easy transition. On the other hand, he is interested in the project and is willing to set up the lists nicely (with archiving and the archives places on both the Web and FTP), and help us in any other way he can. My vote is, of course, to make the project Freeware. This will make everything much easier (especially distributing the money which I don't see how it could have been done in the first place with any degree of fairness and lack of feuding) and it will give us a lot more publicity and fame. Most importantly (to me at least, and probably a number of other people on the project) it will allow many of us to continue work on the project from our accounts. We need to make this decision now. *sigh* --- Charles From ???@??? Sun Apr 02 09:53:51 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id VAA07979 for ; Sun, 26 Mar 1995 21:27:25 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rt4aH-000fIyC; Sun, 26 Mar 95 18:31 PST Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.11/8.6.11) id SAA11704; Sun, 26 Mar 1995 18:28:30 -0800 Date: Sun, 26 Mar 1995 18:28:29 -0800 (PST) From: Greg Taylor To: Directors Subject: OK. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hey all, I see that Jeff, G-J, Martijn and others are all back on line... I'm glad that we can actually begin really rolling on this project! :) I'll do what I can for my groups, but I'm dreadfully busy for the next few months while I finish up my game (June deadline) and my heavy class load this quarter... Anyway, I'm back from spring break and happy to see that other people are back as well.... be typing to ya -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Sun Apr 02 09:53:57 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id VAA08159 for ; Sun, 26 Mar 1995 21:29:33 -0500 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rt4c8-000fIyC; Sun, 26 Mar 95 18:33 PST Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.11/8.6.11) id SAA11841; Sun, 26 Mar 1995 18:30:26 -0800 Date: Sun, 26 Mar 1995 18:30:25 -0800 (PST) From: Greg Taylor To: Directors Subject: Re: Important... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 26 Mar 1995, Jeff Lait wrote: > > > > Count me in with Charles. Though I could technically restrict my > usage to In@sec (My Ottawa provider) and thereby avoid the sticky > legalities, since the start I've always expressed my willingness to make > this freeware w/ code. I highly doubted from the beginning that an > amicable money sharing agreement could be reached, which is why I've > tried to avoid the issue, I'd hate to see this get tied down in > discussing who gets what (Especially when we have yet to decide whos > even doing what :>). > Personally, I've been an idealist who beleives that a the sort of > thing which happend with net hack could happen with an arcade game. > - Jeff Lait (SOL) > My vote also goes to Freeware, the legalities of going commercial keep growing the more we discuss it... Any counter-arguements? -=GT=- > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Sun Apr 02 09:54:04 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id FAA08882 for ; Mon, 27 Mar 1995 05:23:57 -0500 Received: from oliver.sun.ac.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rtBx5-000fIyC; Mon, 27 Mar 95 02:23 PST Received: from styx.sun.ac.za by oliver.sun.ac.za with smtp (Smail3.1.29.0 #2) id m0rtBsA-00159kC; Mon, 27 Mar 95 12:18 EET Received: From SUN_FIRGA/WORKQUEUE by styx.sun.ac.za via Charon-4.0A-VROOM with IPX id 100.950327121910.320; 27 Mar 95 12:19:01 -0200 Message-ID: From: "G-J van Rooyen" <9515291@firga.sun.ac.za> Organization: University of Stellenbosch To: ag-directors@alnilam.krl.caltech.edu Date: Mon, 27 Mar 1995 12:18:58 GMT+200 Subject: Re: Important... Priority: normal X-mailer: Pegasus Mail v3.22 > > Count me in with Charles. > > - Jeff Lait (SOL) > My vote also goes to Freeware, the legalities of going commercial keep > growing the more we discuss it... Any counter-arguements? > -=GT=- The same goes for me. Even though I have no legal restrictions on what I produce on university equipment, there's no practical way for us to release the game commercially. What's important is that we release a Freeware (copyrighted) product. +-------------------------------------------------+ | 9515291@firga.sun.ac.za (Gert-Jan van Rooyen) | | University of Stellenbosch | | South Africa | +-------------------------------------------------+ From ???@??? Sun Apr 02 09:54:30 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id JAA29225 for ; Thu, 30 Mar 1995 09:31:57 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0ruLJk-000fIyC; Thu, 30 Mar 95 06:35 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/30Dec94-1225PM) id AA01468; Thu, 30 Mar 1995 06:30:43 -0800 From: Charles Ofria Message-Id: <9503301430.AA01468@altair.krl.caltech.edu> Subject: Removal.. To: ag-directors@alnilam.krl.caltech.edu Date: Thu, 30 Mar 1995 06:30:43 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 275 Greetings, I just removed (upon his request) belial from all the mailing lists; I noticed he was on the directors list, but he was in virtually every other one as well, so I wasn't sure what he was the director of, so I figured this was probably of note. --- Charles From ???@??? Sun Apr 02 09:54:57 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id NAA02694 for ; Thu, 30 Mar 1995 13:41:40 -0500 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0ruPDI-000fIyC; Thu, 30 Mar 95 10:45 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.11/8.6.11) with ESMTP id UAA25494 for ; Thu, 30 Mar 1995 20:40:02 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.11/8.6.11) id UAA20056 for ag-directors@alnilam.krl.caltech.edu; Thu, 30 Mar 1995 20:39:56 +0200 From: Martijn Faassen Message-Id: <199503301839.UAA20056@laurel.stud.phil.ruu.nl> Subject: Re: Important... (fwd) To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 30 Mar 1995 20:39:55 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 387 Greg Taylor writes: > My vote also goes to Freeware, the legalities of going commercial keep > growing the more we discuss it... Any counter-arguements? I agree the important thing is actually creating the game. So, freeware seems indeed the easiest way to go. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Sun Apr 02 09:53:45 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id UAA05250 for ; Sun, 26 Mar 1995 20:56:22 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rt45U-000fIyC; Sun, 26 Mar 95 17:59 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57081-1>; Sun, 26 Mar 1995 20:54:42 -0500 Date: Sun, 26 Mar 1995 20:54:25 -0500 From: Jeff Lait To: Charles Ofria cc: ag-directors@alnilam.krl.caltech.edu Subject: Re: Important... In-Reply-To: <9503262201.AA16408@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 26 Mar 1995, Charles Ofria wrote: > Greetings, > > My vote is, of course, to make the project Freeware. This > will make everything much easier (especially distributing the money > which I don't see how it could have been done in the first place > with any degree of fairness and lack of feuding) and it will give us > a lot more publicity and fame. Most importantly (to me at least, > and probably a number of other people on the project) it will allow > many of us to continue work on the project from our accounts. > We need to make this decision now. *sigh* > > --- Charles Count me in with Charles. Though I could technically restrict my usage to In@sec (My Ottawa provider) and thereby avoid the sticky legalities, since the start I've always expressed my willingness to make this freeware w/ code. I highly doubted from the beginning that an amicable money sharing agreement could be reached, which is why I've tried to avoid the issue, I'd hate to see this get tied down in discussing who gets what (Especially when we have yet to decide whos even doing what :>). Personally, I've been an idealist who beleives that a the sort of thing which happend with net hack could happen with an arcade game. - Jeff Lait (SOL) From ???@??? Mon Apr 03 17:39:33 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id RAA09566 for ; Mon, 3 Apr 1995 17:31:58 -0400 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rvtfE-000fIyC; Mon, 3 Apr 95 14:28 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id MAA25382 for ; Mon, 3 Apr 1995 12:58:41 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.9) id MAA18364; Mon, 3 Apr 1995 12:58:41 -0700 Message-Id: <199504031958.MAA18364@mcl.mcl.ucsb.edu> Subject: Re: Important... (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Mon, 3 Apr 1995 12:58:40 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 451 > > My vote also goes to Freeware, the legalities of going commercial keep > > growing the more we discuss it... Any counter-arguements? > > I agree the important thing is actually creating the game. So, freeware > seems indeed the easiest way to go. I vote for freeware, too, although I could switch to my commercial account (and if this project extends past June 16, I'll have to) to avoid hassles at my end. So, is that all of the directors? From ???@??? Mon Apr 03 18:09:08 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id RAA14051 for ; Mon, 3 Apr 1995 17:55:27 -0400 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rvu4W-000fJ4C; Mon, 3 Apr 95 14:54 PDT Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id RAA09990 for ; Mon, 3 Apr 1995 17:34:38 -0400 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Apr 1995 17:41:10 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Important... (fwd) >> > My vote also goes to Freeware, the legalities of going commercial keep >> > growing the more we discuss it... Any counter-arguements? >> >> I agree the important thing is actually creating the game. So, freeware >> seems indeed the easiest way to go. > >I vote for freeware, too, although I could switch to my commercial account >(and if this project extends past June 16, I'll have to) to avoid hassles >at my end. > >So, is that all of the directors? Almost...I also vote for freeware...:) --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Mon Apr 03 18:19:00 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id SAA15245 for ; Mon, 3 Apr 1995 18:03:05 -0400 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rvuCy-000fJ2C; Mon, 3 Apr 95 15:02 PDT Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.11/8.6.11) id PAA29313; Mon, 3 Apr 1995 15:02:18 -0700 Date: Mon, 3 Apr 1995 15:02:17 -0700 (PDT) From: Greg Taylor To: Directors Subject: Re: Important... (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > >> > My vote also goes to Freeware, the legalities of going commercial keep > >> > growing the more we discuss it... Any counter-arguements? > >> > >> I agree the important thing is actually creating the game. So, freeware > >> seems indeed the easiest way to go. > > > >I vote for freeware, too, > > Almost...I also vote for freeware...:) > At my count, that's : Freeware : greg, jeff, adrian, mike, charles. Commercial : none. I'm not sure if we've heard from Martijn or G-J or the others(? any more directors that I'm forgetting ?), but I think we can call it a decision, yes? -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Mon Apr 03 18:19:03 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id SAA15942 for ; Mon, 3 Apr 1995 18:06:36 -0400 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rvuGi-000fJ2C; Mon, 3 Apr 95 15:06 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.11/8.6.11) with ESMTP id AAA04622 for ; Tue, 4 Apr 1995 00:04:19 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.11/8.6.11) id AAA17134 for ag-directors@alnilam.krl.caltech.edu; Tue, 4 Apr 1995 00:04:15 +0200 From: Martijn Faassen Message-Id: <199504032204.AAA17134@laurel.stud.phil.ruu.nl> Subject: freeware To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 4 Apr 1995 00:04:14 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 137 You did hear from me, Greg. :) I said, let's go ahead with freeware. (hey, the next game we make can always be commercial. :) Martijn From ???@??? Thu Apr 06 06:58:12 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id GAA05422 for ; Thu, 6 Apr 1995 06:45:55 -0400 Received: from oliver.sun.ac.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rwp37-000fIzC; Thu, 6 Apr 95 03:44 PDT Received: from styx.sun.ac.za by oliver.sun.ac.za with smtp (Smail3.1.29.0 #2) id m0rwoeJ-00159eC; Thu, 6 Apr 95 12:18 EET Received: From SUN_FIRGA/WORKQUEUE by styx.sun.ac.za via Charon-4.0A-VROOM with IPX id 100.950406121933.288; 06 Apr 95 12:20:04 -0200 Message-ID: From: "G-J van Rooyen" <9515291@firga.sun.ac.za> Organization: University of Stellenbosch To: ag-directors@alnilam.krl.caltech.edu Date: Thu, 6 Apr 1995 12:19:19 GMT+200 Subject: Re: Important... X-Confirm-Reading-To: "G-J van Rooyen" <9515291@firga.sun.ac.za> X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail v3.22 My previous attempt at sending this message bounced. Well, here goes again... > At my count, that's : > > Freeware : greg, jeff, adrian, mike, charles. > > Commercial : none. > > I'm not sure if we've heard from Martijn or G-J or the others Yes you did :) My vote was for freeware as well. So I think it's a general concensus. Cheers G-J +-------------------------------------------------+ | 9515291@firga.sun.ac.za (Gert-Jan van Rooyen) | | University of Stellenbosch | | South Africa | +-------------------------------------------------+ From ???@??? Wed Apr 12 10:30:18 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id KAA00473 for ; Wed, 12 Apr 1995 10:22:32 -0400 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rz3FJ-000fIyC; Wed, 12 Apr 95 07:18 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.11/8.6.11) with ESMTP id QAA00628 for ; Wed, 12 Apr 1995 16:15:18 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.11/8.6.11) id QAA21322 for ag-directors@alnilam.krl.caltech.edu; Wed, 12 Apr 1995 16:15:13 +0200 From: Martijn Faassen Message-Id: <199504121415.QAA21322@laurel.stud.phil.ruu.nl> Subject: Status report idea To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Wed, 12 Apr 1995 16:15:13 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 297 If nobody objects, I'm going to send a 'status report' of the alife group to announce (or general? what group would be best) at least once a week. Perhpas this would be an interesting policy for all groups, as I'm curious about the groups I'm not subscribed to (art/sound, front end). Martijn From ???@??? Wed Apr 12 10:50:26 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id KAA04846 for ; Wed, 12 Apr 1995 10:40:08 -0400 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rz3bh-000fIzC; Wed, 12 Apr 95 07:41 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.11/8.6.11) with ESMTP id QAA01033 for ; Wed, 12 Apr 1995 16:38:27 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.11/8.6.11) id QAA21443 for ag-directors@alnilam.krl.caltech.edu; Wed, 12 Apr 1995 16:38:23 +0200 From: Martijn Faassen Message-Id: <199504121438.QAA21443@laurel.stud.phil.ruu.nl> Subject: Plot - Intro Movie To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Wed, 12 Apr 1995 16:38:22 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5100 I took a while, but here's the complete intro plot. I'll work on the rest of it and send that off soon (this time for real). If everybody agrees with it, please forward it to the art/sound group so they can start working? Project Von Neumann ------------------- Screen: Fade in to star field, with a few scattered asteroids, far away, slowly moving. Overlayed Text: 2107 AD, Asteroid Belt, Sol System Screen: Slow pan down. Should last a few seconds. At the bottom a space fighter comes in sight, closer and closer, then pulling up, and shooting through the screen to the top, and out of sight, all very fast. A few plasma bolts flit behind it, then another space fighter (that fired the bolts) shoots up through the screen, just as fast as the first one, but the frame freezes when it's in the middle of the screen. Overlayed Text: The Belt Habitats struggle for independence from the Earth/Moon United Nations, and thought to gain it by threatening Earth with an asteroid bombardment. The EMUN reacts by sending a strike force to the Asteroid Belt, to 'pacify' the Belters. The Solar War has begun. Screen: Fade out. Fade in to large engineering hall. The huge shape of Von Neumann Probe dominates the view, half finished, with people dwarfed by its size working on it. Torchlight glows, sparks fly, giving the impression of feverish activity. Overlayed Text: 2109 AD, secret EMUN base somewhere in Mare on the Moon. The Solar War is still raging, taking a toll of millions, and no end is in sight. EMUN starts the secret project 'Von Neumann', an attempt to create an invincible fleet of self reproducing robotic probes, controlled by EMUN. Screen: Fade out. Fade in to picture of the moon. An small dot appears somewhere on it (in the right mare), grows in size until the finished Von Neumann probe fills the screen. Freeze frame. Overlayed Text: March 8, 2110 AD. The Von Neumann Probe is successfully launched towards the asteroid belt. Able to reproduce, using the raw materials of asteroids, soon there will be many. Equipped with the capacity for mutations, evolution will optimize the probes to the local environment. Screen: Fade to conference table. Men and women with serious faces sit gathered around it. Overlayed Text: 2111 AD. Conference Center in Arcadia Habitat, L5 Peace is signed, unexpected by both sides. The Belt Habitats gain independence, and in exchange EMUN observers will be installed in all Belter military bases. Project Von Neumann is conveniently forgotten about by EMUN officials, and kept secret. Screen: Fade to starfield, a few asteroids in sight. Dominating the view an asteroid with structures (a mining outpost) built on it. The structures are wrecked, half molten, still glowing. Overlayed Text: 2121 AD. Mining Outpost 87 in the Asteroid Belt. 10 years after the end of the Solar War. Unknown attackers leave Mining Outpost 87 a lifeless hulk. Soon after, Military Base A7 and habitat Springtime follow. Investigation ships are sent out to determine the cause. Screen: Fade to starfield, a few asteroids, and *many* distant Probes, swirling, eating asteroid, laying eggs, hatching, shooting at each other. Like a cloud of buzzing insects. Occasionally a probe closerby flits through the screen. The probes vary in shape and color, though some common plan may be recognizable. (this depends on what we'll do exactly to generate the probe sprites, in the game) Overlayed Text: Investigation Ship Tau One sent these pictures back shortly before its destruction. When they reach Earth, project Von Neumann finally comes into the open. The first Von Neumann probe reproduced - unchecked. Evolution went on too long and too far, and the descendants of the first probe are now beyond human control... Screen: Fade in to man and child, viewed from the back, as silouettes. Man has his hand on the shoulder of the child. They are standing in front of a large window, and the stars are visible. After a few moments, distant explosions can be seen, signs of fighting going on out there. The amount and size of explosions increases, and then fairly suddenly dies down. Overlayed Text: Combined EMUN/Belter Fleet operations as visible from Habitat Sunrise in the Belt. EMUN and Belt send a combined fleet to deal with the probes. But, there is too many of them... Screen: Fade to starfield, slowly scrolling. Overlayed Text: From: Combined EMUN/Belt fleet command. Contents of message: The fleet we sent out has been destroyed by the probes. They continue reproducing, and will soon overrun the entire solar system, if not stopped. Proceed building probe modified for human use. It is our only hope. Screen: Still the starfield. Slowly the new probe comes into view. Overlayed Text: 2122 AD. Three months after the destruction of the human fleet. The modified probe, controlled by a human pilot, enters the asteroid belt... -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Wed Apr 12 15:40:16 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id PAA00777 for ; Wed, 12 Apr 1995 15:29:39 -0400 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rz86F-000fIzC; Wed, 12 Apr 95 12:29 PDT Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.11/8.6.11) id MAA24446; Wed, 12 Apr 1995 12:27:59 -0700 Date: Wed, 12 Apr 1995 12:27:59 -0700 (PDT) From: Greg Taylor To: Directors Subject: Re: Status report idea In-Reply-To: <199504121415.QAA21322@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > If nobody objects, I'm going to send a 'status report' of the alife group > to announce (or general? what group would be best) at least once a week. > Perhpas this would be an interesting policy for all groups, as I'm curious > about the groups I'm not subscribed to (art/sound, front end). > I think this is a great idea...I suggest that one of the directors of each group (where there are two) post such a report to ag-general once a week. As for the date...how does Monday sound? It's arbitrary, but it gives a day to think about. Comments? -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Wed Apr 12 18:59:12 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id SAA08539 for ; Wed, 12 Apr 1995 18:42:55 -0400 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rzB6m-000fIyC; Wed, 12 Apr 95 15:42 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id PAA04692 for ; Wed, 12 Apr 1995 15:39:08 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id PAA19126; Wed, 12 Apr 1995 15:39:02 -0700 Message-Id: <199504122239.PAA19126@mcl.mcl.ucsb.edu> Subject: Plot - Intro Movie (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Wed, 12 Apr 1995 15:39:01 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1270 A couple of comments about the plot (mostly grammar checks): > Overlayed Text: > March 8, 2110 AD. > > The Von Neumann Probe is successfully launched towards the asteroid belt. > Able to reproduce, using the raw materials of asteroids, soon there will be ^ should not be there > many. Equipped with the capacity for mutations, evolution will optimize the > probes to the local environment. ... > Overlayed Text: > 2121 AD. Mining Outpost 87 in the Asteroid Belt. > > 10 years after the end of the Solar War. > Unknown attackers leave Mining Outpost 87 a lifeless hulk. Soon after, > Military Base A7 and habitat Springtime follow. Investigation ships are ^ might want to make this capital to conform with the other two locations > sent out to determine the cause. ... > Overlayed Text: > Combined EMUN/Belter Fleet operations as visible from Habitat Sunrise in > the Belt. > > EMUN and Belt send a combined fleet to deal with the probes. But, there > is too many of them... ^ are > > Screen: > Fade to starfield, slowly scrolling. > > Overlayed Text: > I suggest "To: Base Chief (faasen@.moon.mil)" From ???@??? Thu Apr 13 08:07:03 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id HAA27117 for ; Thu, 13 Apr 1995 07:58:22 -0400 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rzNXn-000fIyC; Thu, 13 Apr 95 04:58 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56878-1>; Thu, 13 Apr 1995 07:55:31 -0400 Date: Thu, 13 Apr 1995 07:55:23 -0400 From: Jeff Lait To: Greg Taylor cc: Directors Subject: Re: Status report idea In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Apr 1995, Greg Taylor wrote: > > > > If nobody objects, I'm going to send a 'status report' of the alife group > > to announce (or general? what group would be best) at least once a week. > > Perhpas this would be an interesting policy for all groups, as I'm curious > > about the groups I'm not subscribed to (art/sound, front end). > > > I think this is a great idea...I suggest that one of the directors of > each group (where there are two) post such a report to ag-general once a > week. As for the date...how does Monday sound? It's arbitrary, but it > gives a day to think about. Comments? -=GT=- Agreed. Trouble with this Monday is I'm still off on Easter holidays. I'll see when I can get it in. - Jeff Lait (SOL) From ???@??? Fri Apr 14 02:31:10 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id CAA07637 for ; Fri, 14 Apr 1995 02:24:01 -0400 Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rzeo8-000fJ4C; Thu, 13 Apr 95 23:24 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id aa12841; 14 Apr 95 7:21 GMT-60:00 Received: from darkin.demon.co.uk by post.demon.co.uk id aa05262; 14 Apr 95 7:21 GMT-60:00 Date: Thu, 13 Apr 1995 08:06:26 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <123@darkin.demon.co.uk> To: ag-directors@alnilam.krl.caltech.edu Subject: bizzzz X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 45 Hi all, As the newly created biz director (it`s the post that`s newly created, not me - as far as I`m aware there are no embryos or clones running any of the ag- groups) I just want to find out where we are. Speaking to Greg, he says that there`s a major problem with a commercial release in that many of our members are on college accounts which can`t be used for commercial gain. I think there are ways around that. Firstly, our project is not going to be commercial for a long time (perhaps a year and a half to two years). Even after we finish the programming, a company taking the game on will want to set up marketing and publicity, and prepare its distribution. Even after that, it`s going to be quite a while before money starts to come in from it. Until then we`re not commercial, and nobody can criticise us for *thinking* about starting a bussiness! In the meantime since I`m the only one on the biz group, I`m the only one who`s actually doing anything about it, and I`m not on a school account. It seems that the rules you`ve got are a little unclear anyway. I mean, what happens if you`re doing research for a dissertation using a school account, and then later on decide to work that research into a book, or a magazine article? Do you have to say 'no, can`t do that' just because you used a school account when you were researching? It sounds unlikely, and yet that`s all we`d be doing. Theother way to go about it is to use the system that athletes use: Athletes who take part in the Olympic Games are not allowed to make anything from being athletes. They must be amateurs. What they do, to get around this is to have all the money they make at races put by for them until they retire from athletics. That way they keep their amateur status. Worth considering since I read an article the other day saying that the game Sonic the Hedgehog made more than the film Jurassic Park. Any comments? -- Christian Darkin From ???@??? Fri Apr 14 13:55:58 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id NAA15119 for ; Fri, 14 Apr 1995 13:47:56 -0400 Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rzpRg-000fJ9C; Fri, 14 Apr 95 10:46 PDT Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.11/8.6.11) id KAA01503; Fri, 14 Apr 1995 10:00:34 -0700 Date: Fri, 14 Apr 1995 10:00:33 -0700 (PDT) From: Greg Taylor To: Directors Subject: Re: bizzzz In-Reply-To: <123@darkin.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > Any comments? > Well, since our mailing lists and one of our FTP sites are school sponsored, that might play into it as well....Charles? -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Greg = gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we go = = Taylor - gtaylor@oboe.aix.calpoly.edu = WAAAAAARRRRRRGGGGGG!!! - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ???@??? Fri Apr 14 14:25:53 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id OAA19074 for ; Fri, 14 Apr 1995 14:11:40 -0400 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rzplZ-000fJBC; Fri, 14 Apr 95 11:06 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id JAA02117 for ; Fri, 14 Apr 1995 09:49:55 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id JAA23025; Fri, 14 Apr 1995 09:49:56 -0700 Message-Id: <199504141649.JAA23025@mcl.mcl.ucsb.edu> Subject: bizzzz (fwd) To: ag-directors@alnilam.krl.caltech.edu Date: Fri, 14 Apr 1995 09:49:56 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 523 What I see the suggestions boiling down to is the following: The programmers create the game for no pay, and give it to a company. The company sells it for its own profit, and if it happens to donate some money to the original programmers, it wouldn't be "payment"... Problems: How do we distribute the money, and how do we sell the game? It has been repeatedly suggested that we go via one of the large shareware vendors, or perhaps via Electronic Arts (similar, but it only handles nonshareware, to my knowledge). From ???@??? Fri Apr 14 15:05:47 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id OAA26864 for ; Fri, 14 Apr 1995 14:52:02 -0400 From: charles@krl.caltech.edu Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rzqSN-000fJMC; Fri, 14 Apr 95 11:51 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-1120AM) id AA04071; Fri, 14 Apr 1995 11:47:54 -0700 Message-Id: <9504141847.AA04071@altair.krl.caltech.edu> Subject: Re: bizzzz To: ag-directors@alnilam.krl.caltech.edu Date: Fri, 14 Apr 1995 11:47:54 -0800 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1087 -- By: Greg Taylor > > Any comments? > > > Well, since our mailing lists and one of our FTP sites are school > sponsored, that might play into it as well....Charles? > > -=GT=- As I think I mentioned in my letter on the subject, the sys-admin here doesn't want to support a for-profit project. He says that he will, however, help the project anyway he can (including archiving and making sure the lists don't have to be removed in the future or anything) if its going to be freeware. He also pointed out that it would be against the honor code for me to use my account for a for-profit venture (not that he would report me or stop me, just be disapointed in me probably). Not to mention that Caltech may have some legal rights to the final project (as well as any other university who has someone using an account from it). I think it would overall just be easier as freeware - especially when it comes to who did how much and should get paid how much. I think I'd prefer making a project for everyone to use and enjoy. Then for the next game we write... :-) --- Charles From ???@??? Fri Apr 14 15:25:48 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id PAA29803 for ; Fri, 14 Apr 1995 15:09:29 -0400 From: charles@krl.caltech.edu Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rzqj4-000fJNC; Fri, 14 Apr 95 12:08 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-1120AM) id AA04484; Fri, 14 Apr 1995 12:05:09 -0700 Message-Id: <9504141905.AA04484@altair.krl.caltech.edu> Subject: Re: bizzz To: ag-directors@alnilam.krl.caltech.edu Date: Fri, 14 Apr 1995 12:05:08 -0800 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2515 -- By: Christian Darkin [munch] > Firstly, our project is not going to be commercial for a long time (perhaps a > year and a half to two years). Even after we finish the programming, a > company taking the game on will want to set up marketing and publicity, and > prepare its distribution. Even after that, it`s going to be quite a while > before money starts to come in from it. Until then we`re not commercial, and > nobody can criticise us for *thinking* about starting a bussiness! Ah, but any code written on a computer is owned by the owner of that computer in most cases. Specifically this is true for any university I've ever heard of. As long as none of the programs are written by people on their school accounts, I guess this part can be gotten around, but that will leave me out of coding unfortuantely. I don't know about discussions of new idea, but I don't think that the university will own those ideas. > It seems that the rules you`ve got are a little unclear anyway. I mean, what > happens if you`re doing research for a dissertation using a school account, > and then later on decide to work that research into a book, or a magazine > article? The school *owns* the research you've done. However, that research is not classified (unless you signed beforehand that it would be) so anyone can write a book or a magazine article about it. However in that article you must mention the work having been doen a such-and-such university. If you include a program with your book, you must either include it for free, or else arange something with the university where they get royalties. Read about Stephen Wolfram's expreriances with Mathmatica - something similar happened there, only he did manage to cheat the university out of the money if I remember correctly. I've also heard a number of instances where people left universities when they realized they were about to make a breakthrough so that they could make it in a privately owned buisness. > Do you have to say 'no, can`t do that' just because you used a school account > when you were researching? It sounds unlikely, and yet that`s all we`d be > doing. Slightly different circumstances. They just don't want you to take advantage of their equipment without them reaping part of the benefit. In general they will work with you on selling things as long as they get part of the profit. Heck, Caltech takes 40% of all grants which people at it get, since the work being done is with their equipment. --- Charles From ???@??? Sat Apr 15 08:39:47 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id IAA28600 for ; Sat, 15 Apr 1995 08:24:38 -0400 Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s06sD-000fJ4C; Sat, 15 Apr 95 05:22 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id aa29616; 15 Apr 95 13:20 GMT-60:00 Received: from darkin.demon.co.uk by post.demon.co.uk id aa18278; 15 Apr 95 13:20 GMT-60:00 Date: Sat, 15 Apr 1995 10:11:48 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <125@darkin.demon.co.uk> To: ag-directors@alnilam.krl.caltech.edu Subject: publicity X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 73 In your message dated Friday 14, April 1995 you wrote : > Ah, but any code written on a computer is owned by the owner of that computer > in most cases. Specifically this is true for any university I've ever heard > of. As long as none of the programs are written by people on their school > accounts, I guess this part can be gotten around, but that will leave me out > of coding unfortuantely. I don't know about discussions of new idea, but I > don't think that the university will own those ideas. They just don't want you to take advantage > of their equipment without them reaping part of the benefit. In general they > will work with you on selling things as long as they get part of the profit. > Heck, Caltech takes 40% of all grants which people at it get, since the work > being done is with their equipment. > > --- Charles > Ok, fair enough. I don`t know US rules that well, and I certainly don`t want our project to upset anyone. Especially if part of the reason we`re doing it is for the benefit of research. Let`s go with Freeware and see how it developes. Freeware is going to need twice as much work in publicity to get people to take notice of us. Have you ever seen a games magazine give as much publicity to a freeware game as to a commercial one? - they just don`t do it. The way we have to look at it is that they don`t do it *yet*. We`ve got some very interesting stuff going on in this game. THere`s the AI angle which is going to fire a lot of people`s imagination. The idea that every copy of the game is going to end up being different and that *anything* could happen while playing it is going to be a big attention getter, and the fact that we want people to tell us how their own ecosystems are developing as they play so we can build up global `breeding tanks` from which people can download new creatures for the game whenever they want is going to be interesting. Also the simple fact of the way the game is being put together by people all around the world who have never even met in real life is going to get us publicity. This can all work for us, but only if we use it right. Let`s aim BIG. Let`s aim that when this game gets released, it`s on every magazine cover-disk, in every PD library, and widely distributed over the Internet within a couple of weeks. Lets aim to get coverage worldwide in computer publications, but also in newspapers and TV in every country. It sounds ambitious, I know, but people want to know about this project. It`s really, genuinely ground-breaking in several ways, and it`s also got that `quirky` appeal that the ordinary press like. The first thing to be done, I think is to try to create some kind of expectation leading up to the game`s release. So let`s get an internet mailing list together. What we do is get e-mail addresses for as many computer magazines as we can (games mags, programmer`s mags, Wired, etc) and send them all a press release giving them an idea of what we`re trying to do. We outline the game, and the way we`re putting it together, and give them an idea of our working schedulle (if we can!), and then we say e-mail back if you want to go on our reports list. Whoever does will get regular updates on the work in progress which they can quote from in their news pages if they want to. Ideas, anybody? -- Christian Darkin From ???@??? Sun Apr 16 17:22:41 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id RAA26526 for ; Sun, 16 Apr 1995 17:12:25 -0400 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s0bcm-000fIyC; Sun, 16 Apr 95 14:12 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA00520; Sun, 16 Apr 1995 14:10:15 -0700 Message-Id: <9504162110.AA00520@altair.krl.caltech.edu> Subject: publicity To: ag-directors@krl.caltech.edu Date: Sun, 16 Apr 1995 14:10:10 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4253 -- By: Christian Darkin > Ok, fair enough. I don`t know US rules that well, and I certainly don`t want > our project to upset anyone. Especially if part of the reason we`re doing it > is for the benefit of research. > Let`s go with Freeware and see how it developes. Great! I really think it will turn out best this way. > Freeware is going to need twice as much work in publicity to get people to > take notice of us. Have you ever seen a games magazine give as much > publicity to a freeware game as to a commercial one? - they just don`t do it. > The way we have to look at it is that they don`t do it *yet*. I think if we make it good enough, and talk about it in enough places on the net, it *will* get noticed. A big advantage to it being freeware is that many appropriate newsgroups prohibit in their charter advertising comersial products. On the other had freeware release announcements are perfectly fine. > We`ve got some very interesting stuff going on in this game. THere`s the AI > angle which is going to fire a lot of people`s imagination. The idea that > every copy of the game is going to end up being different and that *anything* > could happen while playing it is going to be a big attention getter, and the > fact that we want people to tell us how their own ecosystems are developing > as they play so we can build up global `breeding tanks` from which people > can download new creatures for the game whenever they want is going to be > interesting. Oh yeah - there are definatly many angles we can take. Especially one where people can link their games into the global breeding tanks - this will make players want to get other players involved so that the tanks get bigger. We can also have contests on who can extract the best creatures from their soups, and who can write the best creatures, and all kinds of things like that. > Also the simple fact of the way the game is being put together by people all > around the world who have never even met in real life is going to get us > publicity. Probably. We also will have many different perspectives on how to get the game known. > This can all work for us, but only if we use it right. > > Let`s aim BIG. Let`s aim that when this game gets released, it`s on every > magazine cover-disk, in every PD library, and widely distributed over the > Internet within a couple of weeks. Lets aim to get coverage worldwide in > computer publications, but also in newspapers and TV in every country. In the end I'd like to aim big, but I've always found that if you have too large an end goal, you get discouraged about ever reaching there. Lets do this one step at a time. I promise you won't have any trouble convincing us for the grandious goals when the time comes. :-) > It sounds ambitious, I know, but people want to know about this project. > It`s really, genuinely ground-breaking in several ways, and it`s also got > that `quirky` appeal that the ordinary press like. Yup. :-) > The first thing to be done, I think is to try to create some kind of > expectation leading up to the game`s release. So let`s get an internet > mailing list together. What we do is get e-mail addresses for as many > computer magazines as we can (games mags, programmer`s mags, Wired, etc) > and send them all a press release giving them an idea of what we`re trying > to do. We outline the game, and the way we`re putting it together, and > give them an idea of our working schedulle (if we can!), and then we say > e-mail back if you want to go on our reports list. Whoever does will get > regular updates on the work in progress which they can quote from in their > news pages if they want to. I think its still a bit to early for this - they won't take us seriously. We should wait until we have something to show before we mention the game to anyone else, and we should wait until the bug-test phase (which will undoubtedly last many months) before we try to build expectation for the realse. I've noticed that we products give a release date, as that date nears it ends up working against them because people expect it out and then its not. I want us to get it out by any date we announce, so we have to be sure of it when we do. --- Charles From ???@??? Fri Apr 21 12:59:54 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id MAA24962 for ; Fri, 21 Apr 1995 12:43:45 -0400 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s2Ll2-000fIyC; Fri, 21 Apr 95 09:40 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id JAA23422 for ; Fri, 21 Apr 1995 09:41:08 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id JAA20783; Fri, 21 Apr 1995 09:41:09 -0700 Message-Id: <199504211641.JAA20783@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report (fwd) To: ag-directors@krl.caltech.edu Date: Fri, 21 Apr 1995 09:41:09 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 574 > What about the ship positions though? The FE- groups need to > know what scale to set the look up tables translating the virtual screens > to the reals creens at. No, they don't. The universe code does not construct a "virtual screen" with the ships in it; the FE code is to take the positions from the objects[] array, as well as any relevant AS variables, and use *those* to create the real screen. The *only* time that the universe code cares about the screen is during menuing and sector selection...it doesn't need to consider the screen during the action. From ???@??? Sun Feb 12 18:55:25 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA20435 for ; Sun, 12 Feb 1995 18:44:25 -0500 Received: from gladstone.uoregon.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rdnzR-000fIvC; Sun, 12 Feb 95 15:46 PST Received: (dave@localhost) by gladstone.uoregon.edu (8.6.9/8.6.5.Beta7) id PAA14868; Sun, 12 Feb 1995 15:43:53 -0800 Date: Sun, 12 Feb 1995 15:43:52 -0800 (PST) From: "David E. Wach" X-Sender: dave@gladstone To: Alife-Game FE-PCX cc: Alife-Game Directors Subject: Demo of 2d Space Scrolling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I was bored and decided to write a simple little demo of 2d space scrolling for the pc. It is on Mike's mac if you would like to take a look at it. You need a file called dos4gw.exe in your path (or on the current directory). It might be on Mike's mac by the time you get this, I am not sure. If you dont have it I can point you as to where to get it. The demo is in the Directory FE-PCX. Tell me what you think. -- Marc Hernandez From ???@??? Sat Apr 22 18:15:12 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id RAA19274 for ; Sat, 22 Apr 1995 17:58:51 -0400 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s2nA9-000fIyC; Sat, 22 Apr 95 14:56 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57053-1>; Sat, 22 Apr 1995 17:56:34 -0400 Date: Sat, 22 Apr 1995 17:56:27 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Re: Universe Status Report (fwd) In-Reply-To: <199504211641.JAA20783@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 21 Apr 1995, Adrian Tymes wrote: > > What about the ship positions though? The FE- groups need to > > know what scale to set the look up tables translating the virtual screens > > to the reals creens at. > > No, they don't. The universe code does not construct a "virtual screen" with > the ships in it; the FE code is to take the positions from the objects[] > array, as well as any relevant AS variables, and use *those* to create the > real screen. The *only* time that the universe code cares about the > screen is during menuing and sector selection...it doesn't need to consider > the screen during the action. Sorry, I should have been more precise. We need to know what SCALE those numbers we rip out of the ship positions are in. After all, all the ship poisition are in terms of distance with relation to a virtual screen, for regardless of the platform, if a ship distance X from yours is at the edge of the screen, it should still be at thte edge of the screen when the user changes res (not that he can change res real time...) You're right - the Universe code doesn't consider the screen during actiuon, but FE- does :> - Jeff Lait (SOL) From ???@??? Sat Apr 22 19:44:54 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id TAA26679 for ; Sat, 22 Apr 1995 19:37:38 -0400 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s2ofr-000fIyC; Sat, 22 Apr 95 16:33 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id QAA01565 for ; Sat, 22 Apr 1995 16:36:08 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id QAA29018; Sat, 22 Apr 1995 16:36:07 -0700 Message-Id: <199504222336.QAA29018@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report (fwd) To: ag-directors@krl.caltech.edu Date: Sat, 22 Apr 1995 16:36:07 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 859 > Sorry, I should have been more precise. We need to know what > SCALE those numbers we rip out of the ship positions are in. After all, > all the ship poisition are in terms of distance with relation to a > virtual screen, for regardless of the platform, if a ship distance X from > yours is at the edge of the screen, it should still be at thte edge of > the screen when the user changes res (not that he can change res real > time...) The x and y variables in an object's record are unsigned short variables denoting the object's center, and their entire range is used, so the universe's "action virtual screen" is 64K * 64K. Note that the universe does not allow creatures bigger than 1K * 1K in these coordinates, and checks for collisions in a 3K * 3K area for each object, so the player should be able to see at least this large of an area. From ???@??? Sun Apr 23 13:31:58 1995 Received: from alnilam.krl.caltech.edu ([131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id NAA06807 for ; Sun, 23 Apr 1995 13:17:30 -0400 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s35DQ-000fJ0C; Sun, 23 Apr 95 10:13 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56842-2>; Sun, 23 Apr 1995 13:13:09 -0400 Date: Sun, 23 Apr 1995 13:13:05 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Re: Universe Status Report (fwd) In-Reply-To: <199504222336.QAA29018@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 22 Apr 1995, Adrian Tymes wrote: > > Sorry, I should have been more precise. We need to know what > > SCALE those numbers we rip out of the ship positions are in. After all, > > all the ship poisition are in terms of distance with relation to a > > virtual screen, for regardless of the platform, if a ship distance X from > > yours is at the edge of the screen, it should still be at thte edge of > > the screen when the user changes res (not that he can change res real > > time...) > > The x and y variables in an object's record are unsigned short variables > denoting the object's center, and their entire range is used, so the Wouldn't it be faster to use longs? After all, we are in a 32bit environment, no? > universe's "action virtual screen" is 64K * 64K. Note that the universe > does not allow creatures bigger than 1K * 1K in these coordinates, and checks > for collisions in a 3K * 3K area for each object, so the player should be > able to see at least this large of an area. > So what's the officially mandated scale? 3096x2304? 3840x3096? Remember, we should keep the 4:3 ratio... - Jeff Lait (SOL) From ???@??? Mon Apr 24 15:18:18 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id PAA28527 for ; Mon, 24 Apr 1995 15:05:07 -0400 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s3TMd-000fJ2C; Mon, 24 Apr 95 12:00 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id MAA24858 for ; Mon, 24 Apr 1995 12:00:23 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id MAA20065; Mon, 24 Apr 1995 12:00:21 -0700 Message-Id: <199504241900.MAA20065@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report (fwd) To: ag-directors@krl.caltech.edu Date: Mon, 24 Apr 1995 12:00:21 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1492 > > > Sorry, I should have been more precise. We need to know what > > > SCALE those numbers we rip out of the ship positions are in. After all, > > > all the ship poisition are in terms of distance with relation to a > > > virtual screen, for regardless of the platform, if a ship distance X from > > > yours is at the edge of the screen, it should still be at thte edge of > > > the screen when the user changes res (not that he can change res real > > > time...) > > > > The x and y variables in an object's record are unsigned short variables > > denoting the object's center, and their entire range is used, so the > > Wouldn't it be faster to use longs? After all, we are in a 32bit > environment, no? TMK, it make no speed difference whether we use short or long x and y variables. Is my information incorrect? We can change this if needed, but I suspect that the other directors may have a lot of their code dependent upon 16 bit x and y positions. > > universe's "action virtual screen" is 64K * 64K. Note that the universe > > does not allow creatures bigger than 1K * 1K in these coordinates, and checks > > for collisions in a 3K * 3K area for each object, so the player should be > > able to see at least this large of an area. > > > So what's the officially mandated scale? 3096x2304? 3840x3096? > Remember, we should keep the 4:3 ratio... How about 3096 * 3096, with the remaining portion of the screen reserved for status diplays, "radar", etc.? From ???@??? Wed Apr 26 07:51:38 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id HAA16418 for ; Wed, 26 Apr 1995 07:39:20 -0400 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s45II-000fIyC; Wed, 26 Apr 95 04:30 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57022-3>; Wed, 26 Apr 1995 07:30:08 -0400 Date: Wed, 26 Apr 1995 07:30:00 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Re: Universe Status Report (fwd) In-Reply-To: <199504241900.MAA20065@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Apr 1995, Adrian Tymes wrote: > > > The x and y variables in an object's record are unsigned short variables > > > denoting the object's center, and their entire range is used, so the > > > > Wouldn't it be faster to use longs? After all, we are in a 32bit > > environment, no? > > TMK, it make no speed difference whether we use short or long x and y > variables. Is my information incorrect? We can change this if needed, > but I suspect that the other directors may have a lot of their code > dependent upon 16 bit x and y positions. > Any calculations with 16 bit values require a operand size prefix, which means an extra byte per instruction. As a result, they must be first promoted to longs before use, so why not use them as 16:16 fixed point and gain an increase in accuracy? > > > universe's "action virtual screen" is 64K * 64K. Note that the universe > > > does not allow creatures bigger than 1K * 1K in these coordinates, and checks > > > for collisions in a 3K * 3K area for each object, so the player should be > > > able to see at least this large of an area. > > > > > So what's the officially mandated scale? 3096x2304? 3840x3096? > > Remember, we should keep the 4:3 ratio... > > How about 3096 * 3096, with the remaining portion of the screen reserved > for status diplays, "radar", etc.? > > Well, if FE-PCX goes with an RLE blitter it doesn't matter where the radar and status windows are placed. So am I to take it that this should use 3840x3096? (That being 3096 in Y as you asked?) - Jeff Lait (SOL) From ???@??? Wed Apr 26 13:06:02 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id MAA04766 for ; Wed, 26 Apr 1995 12:51:14 -0400 Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4AEd-000fIyC; Wed, 26 Apr 95 09:46 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id JAA13438 for ; Wed, 26 Apr 1995 09:46:54 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id JAA18579; Wed, 26 Apr 1995 09:46:49 -0700 Message-Id: <199504261646.JAA18579@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report (fwd) To: ag-directors@krl.caltech.edu Date: Wed, 26 Apr 1995 09:46:49 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1661 > > > > The x and y variables in an object's record are unsigned short variables > > > > denoting the object's center, and their entire range is used, so the > Any calculations with 16 bit values require a operand size > prefix, which means an extra byte per instruction. As a result, they > must be first promoted to longs before use, so why not use them as 16:16 > fixed point and gain an increase in accuracy? I'd rather keep them as integers, but if the other directors don't have a problem with this, I'll change them to longs. > > > > universe's "action virtual screen" is 64K * 64K. Note that the universe > > > > does not allow creatures bigger than 1K * 1K in these coordinates, and checks > > > > for collisions in a 3K * 3K area for each object, so the player should be > > > > able to see at least this large of an area. > Well, if FE-PCX goes with an RLE blitter it doesn't matter where > the radar and status windows are placed. So am I to take it that this > should use 3840x3096? (That being 3096 in Y as you asked?) It does matter what the size of the "viewport" is, as we'll be matching the probes' visual range to the player's visual range. I think that the probes' vision calculations would be made easier if they can see in a square area, so let's give the player a square visual area (3096 * 3096) too. Since this leaves an extra 1024 * 3096 area on the virtual screen, that would probably be where the status reports go. Note that FE_Update() will want to look in a 4K * 4K area around the player, in case there are any large probes whose centers are off the screen but who do extend partially into the player's vision. From ???@??? Wed Apr 26 16:43:03 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id QAA17601 for ; Wed, 26 Apr 1995 16:29:52 -0400 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4Del-000fJ1C; Wed, 26 Apr 95 13:25 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA23948; Wed, 26 Apr 1995 13:26:06 -0700 Message-Id: <9504262026.AA23948@altair.krl.caltech.edu> Subject: Archiving... To: ag-directors@krl.caltech.edu Date: Wed, 26 Apr 1995 13:26:05 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 237 Greetings, So, now that the archiving is working, should I archive the directors group as well? I see no reason why not, especially since the game is going Freeware, but I just thought I should check with you first. --- Charles From ???@??? Wed Apr 26 17:05:42 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id QAA21193 for ; Wed, 26 Apr 1995 16:49:27 -0400 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4Dt4-000fJ0C; Wed, 26 Apr 95 13:40 PDT Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id QAA19667 for ; Wed, 26 Apr 1995 16:40:19 -0400 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Apr 1995 16:47:33 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Archiving... >Greetings, > > So, now that the archiving is working, should I archive the >directors group as well? I see no reason why not, especially since the >game is going Freeware, but I just thought I should check with you >first. > > --- Charles I'd say it should definitely be archived...btw, if we want a back-index, I can send you all the mail from ~Jan 10 'til now..it's about 2 megs uncompressed...compressed should be around half a meg, I'd think...anybody think it's a good idea? --- Michael Mitchener st944m5h@post.drexel.edu From ???@??? Wed Apr 26 21:38:17 1995 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) with SMTP id VAA13102 for ; Wed, 26 Apr 1995 21:29:26 -0400 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4ILw-000fIyC; Wed, 26 Apr 95 18:26 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA29003; Wed, 26 Apr 1995 18:26:59 -0700 Message-Id: <9504270126.AA29003@altair.krl.caltech.edu> Subject: Archiving. To: ag-directors@krl.caltech.edu Date: Wed, 26 Apr 1995 18:26:59 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 142 The directors group is now being archived. If we decide there is going to be a problem with this, I can always remove it. --- Charles From charles Thu Apr 27 10:07:00 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4X1T-000fJ1C; Thu, 27 Apr 95 10:06 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA01024; Thu, 27 Apr 1995 10:06:47 -0700 Message-Id: <9504271706.AA01024@altair.krl.caltech.edu> Subject: ag-amiga group... To: ag-directors Date: Thu, 27 Apr 1995 10:06:47 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 569 Greetings, I just noticed that there is only one person on the ag-amiga mailing lists, and he's not even on the directors list... And I hope he's not wasting the time e-mailing himself :-) Anyway, is it important to keep up an amiga front end? I think we'll have trouble getting people for it, and a pc/mac starting point is not bad at all. If we are going to push for something else, I think unix (as insane an idea as that is) would get us the widest audience. --- Charles PS: The mailing lists can now be accessed properly (I hope) from the ftp site. From phil.ruu.nl!faassen Thu Apr 27 10:22:29 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4XGk-000fJ1C; Thu, 27 Apr 95 10:22 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id TAA11499 for ; Thu, 27 Apr 1995 19:22:29 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id TAA08837 for ag-directors@alnilam.krl.caltech.edu; Thu, 27 Apr 1995 19:22:25 +0200 From: Martijn Faassen Message-Id: <199504271722.TAA08837@laurel.stud.phil.ruu.nl> Subject: Re: ag-amiga group... To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 27 Apr 1995 19:22:24 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1031 > Greetings, > > I just noticed that there is only one person on the ag-amiga > mailing lists, and he's not even on the directors list... And I hope > he's not wasting the time e-mailing himself :-) Anyway, is it important > to keep up an amiga front end? I think we'll have trouble getting people > for it, and a pc/mac starting point is not bad at all. If we are going > to push for something else, I think unix (as insane an idea as that is) > would get us the widest audience. Well, if someone really wants the amiga front end, I suggest them trying to find people for it..If there's people in the group, why not? It can't do any harm keeping it around for now, I suppose. About unix: perhaps easiest would be to develop a Linux version. That probably wouldn't be too difficult a conversion of the PC front end code (though I don't know for sure at all :). Another option might be something that runs under the X windowing system. I'm not at all familiar with X myself though. (yet?) > > --- Charles Martijn From charles Thu Apr 27 10:35:11 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4XT3-000fJ1C; Thu, 27 Apr 95 10:35 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA01786; Thu, 27 Apr 1995 10:35:17 -0700 Message-Id: <9504271735.AA01786@altair.krl.caltech.edu> Subject: Re: ag-amiga group... To: ag-directors Date: Thu, 27 Apr 1995 10:35:17 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 951 -- By: Martijn Faassen > Well, if someone really wants the amiga front end, I suggest them trying > to find people for it..If there's people in the group, why not? It can't > do any harm keeping it around for now, I suppose. Agreed. > About unix: perhaps easiest would be to develop a Linux version. That > probably wouldn't be too difficult a conversion of the PC front end code > (though I don't know for sure at all :). Another option might be > something that runs under the X windowing system. I'm not at all > familiar with X myself though. (yet?) I don't think Linux is all that different from other versions of Unix; I think if we get it going on there it would be fairly easy to port it all over the place. As I'm getting ready for a release version of Avida, I'm certainly learning a heck of a lot about porting :-). Anyway, games of this action level (though uncommon) have been done for X before, such as X-Tank. --- Charles From undergrad.math.uwaterloo.ca!jmlait Thu Apr 27 20:01:47 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4gJM-000fJLC; Thu, 27 Apr 95 20:01 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57047-3>; Thu, 27 Apr 1995 23:01:42 -0400 Date: Thu, 27 Apr 1995 23:01:27 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Re: Universe Status Report (fwd) In-Reply-To: <199504261646.JAA18579@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Apr 1995, Adrian Tymes wrote: > > I'd rather keep them as integers, but if the other directors don't have a > problem with this, I'll change them to longs. > Just a s a reminder to everyone, please keep `short' and `long' distinct, as `int' could refer to either 32 or 16 bits depending upon the system. > > > > > universe's "action virtual screen" is 64K * 64K. Note that the universe > > > > > does not allow creatures bigger than 1K * 1K in these coordinates, and checks > > > > > for collisions in a 3K * 3K area for each object, so the player should be > > > > > able to see at least this large of an area. > > Well, if FE-PCX goes with an RLE blitter it doesn't matter where > > the radar and status windows are placed. So am I to take it that this > > should use 3840x3096? (That being 3096 in Y as you asked?) > > It does matter what the size of the "viewport" is, as we'll be matching the > probes' visual range to the player's visual range. I think that the > probes' vision calculations would be made easier if they can see in a square > area, so let's give the player a square visual area (3096 * 3096) too. Since > this leaves an extra 1024 * 3096 area on the virtual screen, that would > probably be where the status reports go. Note that FE_Update() will want > to look in a 4K * 4K area around the player, in case there are any large > probes whose centers are off the screen but who do extend partially into > the player's vision. Would it be inadmissable to give the player the minor advantage an increased x view would give him (Or visa-versea for the computer player). I'd rather have floating status reports as they allow the user to reposition them as they desire. Another important issue: For speed, I am considering using precompiled rotation functions, which would allow us to have 360 degree resolution without the 90* memory requirements. The trouble is, we need a different sized rotation function for each size image. At a quick guess, we're looking at 10 or so bytes per pixel, so obviously we can't have too many of these rotation functions. So, as I see it our optionns are: 1) Tile the large ships, ie: make them out of many ships of a given size. Give it to FE-PCX as if it were many ships. 2) Have only a few fixed sized ships. Also, in order to remove the necessity of clipping code, we'll need to set a maximum size to the sprites. (Currently, 1/10 of the physical screen size). This maximum size cannot be increased to much as we'd need to worry as well about the speed hit of building a larger virtual screen. What do the MAC people think about what I outlined? - Jeff lait (SOL) From mcl.ucsb.edu!uwingcat Thu Apr 27 20:21:11 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4gc8-000fJMC; Thu, 27 Apr 95 20:21 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id UAA12854 for ; Thu, 27 Apr 1995 20:21:17 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id UAA22572; Thu, 27 Apr 1995 20:21:16 -0700 Message-Id: <199504280321.UAA22572@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report (fwd) To: ag-directors@krl.caltech.edu Date: Thu, 27 Apr 1995 20:21:16 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3179 > > I'd rather keep them as integers, but if the other directors don't have a > > problem with this, I'll change them to longs. > > > Just a s a reminder to everyone, please keep `short' and `long' > distinct, as `int' could refer to either 32 or 16 bits depending upon the > system. In this case, I meant integer as opposed to fixed point. Given the torriodal space we're probably going to use, we should make them unsigned long ints, and ignore the most significant 16 bits (also ignore over/underflow when the universe code adjusts their positions). > > It does matter what the size of the "viewport" is, as we'll be matching the > > probes' visual range to the player's visual range. I think that the > > probes' vision calculations would be made easier if they can see in a square > > area, so let's give the player a square visual area (3096 * 3096) too. Since > > this leaves an extra 1024 * 3096 area on the virtual screen, that would > > probably be where the status reports go. Note that FE_Update() will want > > to look in a 4K * 4K area around the player, in case there are any large > > probes whose centers are off the screen but who do extend partially into > > the player's vision. > > Would it be inadmissable to give the player the minor advantage > an increased x view would give him (Or visa-versea for the computer > player). I'd rather have floating status reports as they allow the user > to reposition them as they desire. Martijn? Would this be allowable? > Another important issue: For speed, I am considering using > precompiled rotation functions, which would allow us to have 360 degree > resolution without the 90* memory requirements. The trouble is, we need > a different sized rotation function for each size image. At a quick > guess, we're looking at 10 or so bytes per pixel, so obviously we can't > have too many of these rotation functions. So, as I see it our optionns are: > 1) Tile the large ships, ie: make them out of many ships of a > given size. Give it to FE-PCX as if it were many ships. > 2) Have only a few fixed sized ships. #2 is *much* more favorable. BTW, UN_InitTable will be pre-defining sin(char degree) and cos(char degree) for the 256 degree system used by the objects, and we will not #include . UN_InitTable() is called just after FE_InitSystem(); should the sin() and cos() tables be generated in FE_InitSystem instead? If so, UN_InitTable() will do nothing, and can be dropped. > Also, in order to remove the necessity of clipping code, we'll > need to set a maximum size to the sprites. (Currently, 1/10 of the > physical screen size). This maximum size cannot be increased to much as > we'd need to worry as well about the speed hit of building a larger > virtual screen. The maximum size of a ship in universe virtual coordinates is no larger than a subsector (1K * 1K on its 64K * 64K field). But I think that there were requests for ships approx. 1/5 screen by 1/5 screen ("boss" probes). We could merge both of these requests by upping the displayed area to 5K * 5K in universe coordinates, although this would mean that more objects will be drawn. From post.demon.co.uk!darkin.demon.co.uk!Christian Fri Apr 28 01:16:04 1995 Return-Path: <@post.demon.co.uk:Christian@darkin.demon.co.uk> Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4lDV-000fJMC; Fri, 28 Apr 95 01:16 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id ab25687; 28 Apr 95 9:15 GMT-60:00 Received: from darkin.demon.co.uk by post.demon.co.uk id aa19335; 28 Apr 95 9:15 GMT-60:00 Date: Thu, 27 Apr 1995 17:54:01 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <144@darkin.demon.co.uk> To: ag-directors@alnilam.krl.caltech.edu Subject: Re: ag-amiga group... X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 32 In your message dated Thursday 27, April 1995 you wrote : > Greetings, > > I just noticed that there is only one person on the ag-amiga > mailing lists, and he's not even on the directors list... And I hope > he's not wasting the time e-mailing himself :-) Anyway, is it important > to keep up an amiga front end? I think we'll have trouble getting people > for it, and a pc/mac starting point is not bad at all. If we are going > to push for something else, I think unix (as insane an idea as that is) > would get us the widest audience. Well, I would have been interested in the Amiga group only I sold mine on tuesday. :) I`ve just moved on to a PC. I must say I do think the Amiga`s got a lot of life in it yet. It`s also where you find a hell of a lot of games players. There`s not the market for it in the States, (except for as a video effects machine) but over here it`s the most popular non PC platform. If we can keep the Amiga end going, it would be quite popular outside of the US and it would get a lot of people playing who aren`t necessarily committed computer users, just games players, so we`d get some feedback from that as well. The Amiga does have 16,000,000 colours as standard, and a sound system which is well up to most PC boards, and Amiga games are well up to the standard of PC ones generally. Having said that, the A1200 which is what most people have has only 2meg as standard and runs at 14Mhz so it might not be up to our game. -- Christian Darkin From charles Fri Apr 28 09:12:55 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4sdl-000fJQC; Fri, 28 Apr 95 09:11 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA12484; Fri, 28 Apr 1995 09:11:43 -0700 Message-Id: <9504281611.AA12484@altair.krl.caltech.edu> Subject: Web questions... To: ag-directors, ag-universe, ag-alife Date: Fri, 28 Apr 1995 09:11:43 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 411 Greetings, I want to get some ideas about the web page, so I have two quick questions; How many of you have personal web pages, which I may hook in depending on how things work out. Also, how many of you *don't* have web access at all (I think most of you do, so only tell me if you don't). I generally want to know how much stuff I need to duplicate in the ftp site. FAQ v0.2 to follow. --- Charles From charles Fri Apr 28 09:37:24 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4t1P-000fJRC; Fri, 28 Apr 95 09:36 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA12271; Fri, 28 Apr 1995 09:36:08 -0700 Message-Id: <9504281636.AA12271@altair.krl.caltech.edu> Subject: FAQ version 0.2 alpha To: ag-alife, ag-universe, ag-directors Date: Fri, 28 Apr 1995 09:36:08 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 16780 Included here is the latest version of the FAQ I'm working on for the game, and I must say its getting quite long - with a lot left to be filled in. As soon as this is done I'll stick it up as a web page, but please lets make sure we have it good by then. I'm sending this version to everyone actively working on the game, so please don't immediately overwhelm me with responces to merge togeather. I think the optimal way of doing this is for anyone who wants to work on a section to just make a quick post to ag-general that they are and thus no one else should or else work will be duplicated. Effictively a poorly done RCS :-). Anyway, please fill in sections, edit sections, and genreally make the whole thing better. I put in everything I could think of off hand, but I'm sure I still missed a lot. ****** begin ****** Project: Von-Neumann I) Game Concepts : Player's view (or - what is this game all about anyway?) Imagine yourself flying through a vast asteroid belt with alien creatures on all sides; some of them predators with you as their prey. You must drive to the heart of their realm and find a way to rid the universe of their threat once and for all - you are the universes last hope. Sounds typical, eh? Fear not, there more to this game then that. The interface is standard for many shoot-em-up games - you have a ship in a 2-D universe which you can move forward, backward, turn, fire, and other normal abilities. What is not so standard is the fact that as you go up levels, your enemies don't get stronger than you; they just get smarter! * they have approximately the same shielding you. * on the average, they cause the same damage as you. * travel at the same speed. * see as far. * turn as fast. - but things get harder! As your skill improves, so does your opponents. When you develop a great new strategy, they develop a great new counter move. When you learn to dodge, they learn to follow. Furthermore your opponents are real creatures, with their own agenda's, motives, weaknesses and needs. They aren't merely mindless brutes programmed only to hunt you down. Potentially you could even breed a domesticated strain to help you ! All your opponentsare as powerful as you are, but they're only trying to survive - killing you is only one of things which could aid them in their goal. You survive only on their terms and adapt to their system - otherwise you're just another dying breed. When you first enter this deadly world, a delicate balance will have already been established in the ecosystem. You are bound to disrupt this system by adding in a new component to the environment which the inhabitants will adapt to - be it a symbiotic evolution for some, or predator-pray for others. Now all you have to do is keep up. --------------------------------------------- II) Game Concepts : ALife view. (or, Real creatures, huh?) The Alife units (henceforth called probes) are all given the same abilities as the player; effectively they only have a virtual keyboard in front of them as their only way to control their own bodies. Anything they player can do, the Alife engines can do, and nothing more. Their will, however, be primitive methods of communication available to be used and hopefully developed by the probes, and possibly (though unlikely) crackable by the player. The simulation will be seeded with a handful of different programmer written probes (in an easily and robustly mutable code) and then run until as sophisticated and ecosystem as possible has developed. Then it comes time for the player... --------------------------------------------- III) Before the game... Someone else do this? --------------------------------------------- IV) Okay - so what about the plot once the game starts? We could tell you but then we'd have to kill you. Or at least ruin your fun in playing the game. We'll keep this (as soon as we finish writing it) as a seperate document at the ftp site so you'll have to go out of your way to spoil the game for yourself. But seriously, we are developing a semi-intricate plot (nothing hard to follow though) where the player makes discoveries and advances thoughout the game in a quest to learn whats really going on - and stop it. --------------------------------------------- V) What will the ships (both alien and player) be like? The ships will have a number of statistics including: (someone else on the universe team is going to really have to fix this up!) Shields (Hit Points loss of which doesn't cause internal damage) Hull Strength (Hit Points when lost may cause systems failues) Weapons (of all different types - most to be discovered) Max Velocity Max Acceleration Manuverabity (turn radius) Scanners Lots of special powers. (I know I'm forgetting a lot, and probably including a lot I shouldn't) --------------------------------------------- VI) How can the ships improve? Well, there are a couple of different ways. First, you can eat aliens and strip their corpses to gain more energy (and ammo??? anything else?). Next you can send some of the corpses back to a nearby supply ship for refitting to give you extra lives later on. Of course you's only want to send the best ships back for this since you want to be flying in something decent. Finally you can send the ship all the way back to the lunar scientists who will research the ships systems and be able to send you upgrades in equipment for your own ship, as well as other technological breakthroughs. A complete list of technologies (once written) will be located at the ftp site. --------------------------------------------- VII) What is the basic construction for the ALife engine? We've spent the past few months trying to come up with the perfect construct to control these probes, but have only discovered that there is no way to be sure of any of them without trying it. Some seem to brittle to be mutated properly, others will take too long to mutate into something useful, and still others just don't have the upward potential that we want them to have. Then there are always the real-world problems of speed, memory, and having programmers willing to put together these horribly complex things. We finally settled on a three-phase approach: 1: Start with a simple gene-based model. There will be a handful of genes, each of a specific type (such a combat gene, reproduction gene, etc) with a number of each type pre-programmed ahead of time. This model has no ability of mutation within a gene, thus the only real evolvability is in finding optimal combinations of the pre-existing genes. The good parts are that is fast to write (and to run) and thus will give us something good to start testing the rest of the system with. The other good point to it is that it is extremely non-brittle. 2: The next step is to make each gene evolvable (and thus without any "pure" meaning behind them. We want to do this (I think?) by using a straight-forward genetic programming tree. Each gene would be initially coded for a specific task, but then could evolve into just about anything. Someone else should probably write a lot more on this, including more detail on exactly what a GP-tree is. 3: Move on to more advanced ideas and try the different engines against each other to determine the true plusses and minuses of each. --------------------------------------------- VIII) What were the other possible engines discussed? Neural-Networks: This would have been a very simple and straightforward model where the inputs are whatever sensors we give the probes, and the outputs are key-presses. The two problems (which led us to putting these on the back- burner to be thought about more in the future) are that they are nearly impossible to evolve (slight changes tend to break them) and its also quite difficult to write an initial probe which works. Virtual Machine Code: This method was a close second for the probes control engines. The advantages were that the method can be ensured to be Turing complete and the landscape of possibilities could be made more fully connected, but it was decided that the GP's stood more potential for getting good evolution faster, and their possibly lesser upper limits would never be reached. GP-instantiated VMC: I think most of us agree that this method has the most potential. The way it works is that there are a series of commands (as in vertual machine code), but each of these commands is actually a small GP. The GP's would be made extremely versatile (although potentially brittle) so that commands could be made which could do anything, but most of the evolution would (probably) take place on the level of the VMC. This method gives the best of both worlds to the evolution of the probes, but unfortunately the worst of both worlds to the programmers (and maybe the CPU depending on how its done). Brain-in-a-Box: An early plan was that loosing players would have the tops of their heads sawn off and their brains extracted and kept alive in a nutrient tank, permanently plugged into the game. These brains would then provide a "human strategy database" of subroutines for seeding new aliens. The idea was rejected on some obscure legal grounds in certain countries we want to have the game releasable in. ------------------------------------------------------ IX) What is the structure used for the universe part of the game? (I just wanted something here on the inner workings of the main body of the game - can someone else write this section?) ------------------------------------------------------ X) What mailings lists are there for the group? There are 9 mailing list associated with this project; they are: ag-universe: This group is making the main body of the game, designing the enviornment, story line, wining conditions, etc. ag-alife: Dedicated to the discusion of making an optimal evilutionary system and to give the players as much of a challenge as possible. The alife-engines will plug directly into the ships in the universe in a similar fashion to how the player controls his own ships. ag-pcx, ag-mac, and ag-amiga: Dedicated to designing the user interfaces on these three platforms. ag-directors: Each group has one or two people nominaly in charge. This is simply a group of them and is dedicated to keeping the project going on all fronts and making global decisions. ag-art-sound: This group designs the evolving music and pictures in the game, as well as the graphics for the opening sequence. ag-general: This group simple redirects mesages to the members of all the other groups, and is a good way of broadcasting important things. ag-announce: This final group is simply for people periferally interested in the game who want to get the occasional progress reports when major parts are accomplished. To send E-Mail to any of these lists, simply send it to: @krl.caltech.edu If you want to be added onto one of these lists, E-Mail me at charles@krl.caltech.edu. ------------------------------------------------------ XI) What about the ftp/archive/web site? The ftp site is located at ftp.krl.caltech.edu in the pub/alife-game directory. Feel free to look around there. A full archive of all the messages sent in the various groups is kept there as well in the archive sub-directory. A web page is currently being constructed, and will be located at: ------------------------------------------------------ XII) Who is running this project anyway? There are 8 of us who (as I mentioned before) are nominally in charge of the game. To the best of my knowledge the directors positions have only added responcibility, but these are the people who keep the game going. In general all participants in a debate have equal influence, and the only power of a director is to break a deadlock if it lasts too long. (Heck, both of the directors of the alife group wanted an engine other then the one we finallly went for :-) ) Greg Taylor (gtaylor@galaxy.csc.calpoly.edu) - The head of the project, and 'director' of the ag-directors group. Charles Ofria (charles@krl.caltech.edu) - Co-Director of ag-alife group, and maintainer of the ftp/web site and this FAQ. Martijn Faassen (faassen@phil.ruu.nl) - Co-Director of the ag-alife group. Adrian Tymes (uwingcat@mcl.mcl.ucsb.edu) - Director of the ag-universe group. Jeff Lait (jmlait@undergrad.math.waterloo.ca) Director of the ag-pcx and ag-art-sound groups. Mike Mitchener (st944m5h@post.drexel.edu) Director of the ag-mac group. Christian Darkin (Christian@darkin.demon.co.uk) Director of the publicty aspects of the game (no associated mailing list, unless there becomes a call for one). Gert-Jan van Rooyen (9515291@firga.sun.ac.za) ??? ------------------------------------------------------ XIII) Glossery of Terms: (Should these be in something other than alphabetical order? Also, please edit, expand/expound on these, etc.) *** Game Specific Terms *** Alife Engine: The program which contols the individual probes in the game. These programs are in a language designed to be easily mutatable and robust. Probe: All of the non-player creatures in the game. (should say more here...) Sector: The game space is divided into 16 of these in 7 diagonal bands. Each time a new band is passed, a "progress report" movie is played. Only one sector is in play at any one time. Subsector: Each sector is divided into a 64 * 64 array of subsectors to speed up collision detection. No object may be larger than one subsector, although large objects will frequently overlap the borders between sectors. Standard visual range for probes and the player is a square 3 * 3 subsector area. *** Related Alife Terms *** (And how they relate to the game) Alife: The study of life and its processes through simulation and recreation. This game uses many of the life processes within the probes in order to make them able to adapt to their environment. Auto-Adaptive System: A system of part which will align or otherwise re-order themselves without outside interference. Project: Von Neumann is a perfect example of this as the probes will adapt to their environment (including the player) without an outside force making or directing them. Evolution: A stocastic process driven by mutations and directed by natural selection which causes a population to adapt to their environment. GP: (could someone fill in the begining of this?) This is the idea behind the control code we have finally Life: I won't even try defining this one. :-) Mutation: A (usually) random change in a structure. In this game, we mutate the control code of the creatures to create diversity (thus driving the evolution), and then let natural selection screen out the best. Natural Selection: The process which simply states that the types of creatures which reproduce the most overall will end up with the most numbers in the end (logical, no?). The two classic things which natural selection pushes for are being able to survive longer (and thus having more time to reproduce), and being able to reproduce faster. Neural Network: A model of the human brain which theoretically can be as powerful, but we still have very little knowledge on the optimal ways of constructing them. A possible model used for a future alife engine. Turing Complete: A language is considered Turing Complete if it is able to compute any function computable. It is still counted even if it takes the language a huge amount of time and memory to complete this function. It is somewhat important to try to make the Alife Engine turing complete so that we can try to maximize the possible behaviors evolvable in the creatures. Virtual Machine Code: An extremely simplified assembly language run off of a simulated CPU (in out case, in the Alife engine). This was another consideration for the engine, and will probably be implemented in a later version. Von-Neumann: Hungarian-born German-American mathematician who made important contributions in quantum physics, logic, meteorology, and computer science. His theory of games had a significant influence upon economics. He was the founder of many of the concepts which later coallesed into the field of Artifical Life. ------------------------------------------------------ XIV) Pointers to related things. relevent newsgroups (plus their associated FAQ's): comp.ai.alife comp.ai.games comp.ai.genetic comp.ai.neural-nets rec.games.programmer rec.games.design sci.bio.evolution Sites on the web... The Avida Research Group: (I'm not sure what else - please people add more) From undergrad.math.uwaterloo.ca!jmlait Fri Apr 28 14:14:46 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4xN4-000fJWC; Fri, 28 Apr 95 14:14 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57100-2>; Fri, 28 Apr 1995 17:14:08 -0400 Date: Fri, 28 Apr 1995 17:14:06 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Re: Universe Status Report (fwd) In-Reply-To: <199504280321.UAA22572@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 27 Apr 1995, Adrian Tymes wrote: > > > I'd rather keep them as integers, but if the other directors don't have a > > > problem with this, I'll change them to longs. > > > > > Just a s a reminder to everyone, please keep `short' and `long' > > distinct, as `int' could refer to either 32 or 16 bits depending upon the > > system. > > In this case, I meant integer as opposed to fixed point. Given the > torriodal space we're probably going to use, we should make them unsigned > long ints, and ignore the most significant 16 bits (also ignore > over/underflow when the universe code adjusts their positions). > Okay. Doens't matter to FE overmuch, just so long as you can get the precision with small delta vs which may be required. > > Another important issue: For speed, I am considering using > > precompiled rotation functions, which would allow us to have 360 degree > > resolution without the 90* memory requirements. The trouble is, we need > > a different sized rotation function for each size image. At a quick > > guess, we're looking at 10 or so bytes per pixel, so obviously we can't > > have too many of these rotation functions. So, as I see it our optionns are: > > 1) Tile the large ships, ie: make them out of many ships of a > > given size. Give it to FE-PCX as if it were many ships. > > 2) Have only a few fixed sized ships. > > #2 is *much* more favorable. Agreed. From FE's end both are equivalent, but from Universe's perspective 2 is definitely preferrable :> > BTW, UN_InitTable will be pre-defining sin(char degree) and cos(char degree) > for the 256 degree system used by the objects, and we will not > #include . UN_InitTable() is called just after FE_InitSystem(); > should the sin() and cos() tables be generated in FE_InitSystem instead? > If so, UN_InitTable() will do nothing, and can be dropped. > Shouldn't the table initialization take place before FE_InitSystem? That way, it doesn't need to be transferred to the front end & the FE can use the look up table. > > Also, in order to remove the necessity of clipping code, we'll > > need to set a maximum size to the sprites. (Currently, 1/10 of the > > physical screen size). This maximum size cannot be increased to much as > > we'd need to worry as well about the speed hit of building a larger > > virtual screen. > > The maximum size of a ship in universe virtual coordinates is no larger than > a subsector (1K * 1K on its 64K * 64K field). But I think that there were > requests for ships approx. 1/5 screen by 1/5 screen ("boss" probes). We > could merge both of these requests by upping the displayed area to 5K * 5K > in universe coordinates, although this would mean that more objects will > be drawn. > Okay, 1/5 by 1/5 would have to be broken up. Why the might? In order to avoid the usual problems of clipping, we're drawing to a virtual screen padded on each side by one tile. Currently, (And arbitrarily) the tile size is 32 bytes. By drawning an extra tile on each side, we can easily scroll & avoid any clipping worries. The latter is only possible if the ojects are at most one tile in size. (Clipping could be hacked in, but it wouldn't be fun (A bit of S-M :>) and would require about 64* the memory for a 32x32 object.) 1/10 is possibel as that's 32x32. Of course, we could increase tile size, bnut that increases mem req'ments and cpu load. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Fri Apr 28 14:19:39 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s4xRo-000fJXC; Fri, 28 Apr 95 14:19 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57109-2>; Fri, 28 Apr 1995 17:17:13 -0400 Date: Fri, 28 Apr 1995 17:17:00 -0400 From: Jeff Lait To: Christian Darkin cc: ag-directors@alnilam.krl.caltech.edu Subject: Re: ag-amiga group... In-Reply-To: <144@darkin.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 27 Apr 1995, Christian Darkin wrote: > > The Amiga does have 16,000,000 colours as standard, and a sound system > which is well up to most PC boards, and Amiga games are well up to the standard > of PC ones generally. Having said that, the A1200 which is what most people > have has only 2meg as standard and runs at 14Mhz so it might not be up to our > game. > A video game in 24bit colour on a machine with 2mb and 14 mHz? Try 256 colours if you want real time & nno virtual memory :> From post.demon.co.uk!darkin.demon.co.uk!Christian Sat Apr 29 03:27:26 1995 Return-Path: <@post.demon.co.uk:Christian@darkin.demon.co.uk> Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s59kA-000fJZC; Sat, 29 Apr 95 03:27 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id ab13232; 29 Apr 95 11:27 GMT-60:00 Received: from darkin.demon.co.uk by post.demon.co.uk id aa15639; 29 Apr 95 11:27 GMT-60:00 Date: Sat, 29 Apr 1995 08:58:52 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <152@darkin.demon.co.uk> To: ag-directors@alnilam.krl.caltech.edu Cc: ag-art-sound@krl.caltech.edu Subject: size of game X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 28 Hi all, I`ve been thinking recently about how big this game is going to be (in terms of disk space). I realise that now is far too early to be sure, but the way I see it, our major ways of distributing the game are going to be via PD libraries, magazine cover-disks, and over the internet. Now, I`m no expert, but if we`re going to need one disk (at least) full of probes to begin the game, and one disk of program data, and another disk for our opening movie, and then we`re going to put in extra movies when you go up a level, or make a discovery, then we`re going to take up a lot of space. Who`s going to want to download 5Mb of data just to play the game? Who`s going to agree to distribute 3 or 4 disks free with their magazine? It`s a bit of a problem. Perhaps we ought to think about a cut-down version (ie. without the flashy intros and movies) for floppy disk distribution, and then a super version (with all the extra probes, and video sequences we like) for CD rom users. What I guess I`m saying is that maybe we ought to decide now how much graphics space we want to take up, and then we`ll know what we can and can`t achieve. -- Christian Darkin From undergrad.math.uwaterloo.ca!jmlait Sat Apr 29 09:02:27 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5EyO-000fJYC; Sat, 29 Apr 95 09:02 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56875-1>; Sat, 29 Apr 1995 12:01:06 -0400 Date: Sat, 29 Apr 1995 12:01:00 -0400 From: Jeff Lait To: Christian Darkin cc: ag-directors@alnilam.krl.caltech.edu, ag-art-sound@krl.caltech.edu Subject: Re: size of game In-Reply-To: <152@darkin.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 29 Apr 1995, Christian Darkin wrote: > Hi all, > > I`ve been thinking recently about how big this game is going to be (in terms of > disk space). I realise that now is far too early to be sure, but the way I see > it, our major ways of distributing the game are going to be via PD libraries, > magazine cover-disks, and over the internet. > > Now, I`m no expert, but if we`re going to need one disk (at least) full of > probes to begin the game, and one disk of program data, and another disk for our > opening movie, and then we`re going to put in extra movies when you go up a > level, or make a discovery, then we`re going to take up a lot of space. > Won't need a full disk for programming data. If we have probe graphics generated algorithmically, they won't take much space. As for the movies, I suggest we have the movies as entirely optional, ie: if they aren't on the persons hard drive, we just do some text thing. In that way, we can have a seperate disk of movies which people can download or not as they please. Also, anyone with limitted diskspace can trash the movies as soon as they are finished with them. > Who`s going to want to download 5Mb of data just to play the game? Who`s going > to agree to distribute 3 or 4 disks free with their magazine? > Depend how good a game it is :> > What I guess I`m saying is that maybe we ought to decide now how much graphics > space we want to take up, and then we`ll know what we can and can`t achieve. The only thing taking serious room from what I see will be the movies. - Jeff Lait (SOL) From mcl.ucsb.edu!uwingcat Sat Apr 29 12:57:31 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5Ids-000fJYC; Sat, 29 Apr 95 12:57 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id MAA19906 for ; Sat, 29 Apr 1995 12:57:22 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id MAA08780; Sat, 29 Apr 1995 12:57:25 -0700 Message-Id: <199504291957.MAA08780@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report (fwd) To: ag-directors@krl.caltech.edu Date: Sat, 29 Apr 1995 12:57:24 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4297 > > In this case, I meant integer as opposed to fixed point. Given the > > torriodal space we're probably going to use, we should make them unsigned > > long ints, and ignore the most significant 16 bits (also ignore > > over/underflow when the universe code adjusts their positions). > > > Okay. Doens't matter to FE overmuch, just so long as you can get > the precision with small delta vs which may be required. I think that 1024 * 1024 places per subsector is enough precision. > > > Another important issue: For speed, I am considering using > > > precompiled rotation functions, which would allow us to have 360 degree > > > resolution without the 90* memory requirements. The trouble is, we need > > > a different sized rotation function for each size image. At a quick > > > guess, we're looking at 10 or so bytes per pixel, so obviously we can't > > > have too many of these rotation functions. So, as I see it our optionns are: > > > 1) Tile the large ships, ie: make them out of many ships of a > > > given size. Give it to FE-PCX as if it were many ships. > > > 2) Have only a few fixed sized ships. > > > > #2 is *much* more favorable. > > Agreed. From FE's end both are equivalent, but from Universe's > perspective 2 is definitely preferrable :> The size of the object's bounding box will be in object[].bboxside; FE can read that. BTW, would it be feasable for FE to run a bitmap check if two objects' bounding boxes overlap during the universe's collision detection? If not, we're going to be stuck with bounding box collisions. > > BTW, UN_InitTable will be pre-defining sin(char degree) and cos(char degree) > > for the 256 degree system used by the objects, and we will not > > #include . UN_InitTable() is called just after FE_InitSystem(); > > should the sin() and cos() tables be generated in FE_InitSystem instead? > > If so, UN_InitTable() will do nothing, and can be dropped. > > > Shouldn't the table initialization take place before > FE_InitSystem? That way, it doesn't need to be transferred to the front > end & the FE can use the look up table. Like I typed, why not just put the table initialization into FE_InitSystem()? sin() and cos() will be accessed every time something turns, so they should be put into quickly accessable memory. > > > Also, in order to remove the necessity of clipping code, we'll > > > need to set a maximum size to the sprites. (Currently, 1/10 of the > > > physical screen size). This maximum size cannot be increased to much as > > > we'd need to worry as well about the speed hit of building a larger > > > virtual screen. > > > > The maximum size of a ship in universe virtual coordinates is no larger than > > a subsector (1K * 1K on its 64K * 64K field). But I think that there were > > requests for ships approx. 1/5 screen by 1/5 screen ("boss" probes). We > > could merge both of these requests by upping the displayed area to 5K * 5K > > in universe coordinates, although this would mean that more objects will > > be drawn. > > > Okay, 1/5 by 1/5 would have to be broken up. Why the > might? In order to avoid the usual problems of clipping, we're drawing to a virtual screen > padded on each side by one tile. Currently, (And arbitrarily) the tile > size is 32 bytes. By drawning an extra tile on each side, we can easily > scroll & avoid any clipping worries. The latter is only possible if the > ojects are at most one tile in size. (Clipping could be hacked in, but > it wouldn't be fun (A bit of S-M :>) and would require about 64* the > memory for a 32x32 object.) > 1/10 is possibel as that's 32x32. Of course, we could increase > tile size, bnut that increases mem req'ments and cpu load. I'm in favor of keeping maximum FE object size approx. = UN object size. So, other directors, should we go for smaller objects or a faster update? I think that if we want objects no larger than 1/10 of the screen, we'd best give the player a 10 * 10 subsector view (and adjust the probes' scanning range accordingly). This would mean that each subsector could be treated as a tile, although their contents would change between updates and some tiles could overlap the screen's edge. In addition, the objects could overlap a tile's edge. From wam.umd.edu!keithw Sat Apr 29 14:18:04 1995 Return-Path: Received: from wor-srv.wam.umd.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5Jto-000fJZC; Sat, 29 Apr 95 14:18 PDT Received: from rac1.wam.umd.edu (keithw@rac1.wam.umd.edu [128.8.70.3]) by wor-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id RAA18442; Sat, 29 Apr 1995 17:17:55 -0400 Received: (keithw@localhost) by rac1.wam.umd.edu (8.6.10/8.6.10) id RAA15584; Sat, 29 Apr 1995 17:17:54 -0400 Date: Sat, 29 Apr 1995 17:17:53 -0400 (EDT) From: Keith Wiley To: Christian Darkin cc: ag-directors@alnilam.krl.caltech.edu, ag-art-sound@krl.caltech.edu Subject: Re: size of game In-Reply-To: <153@darkin.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Regarding the following post, I disagree completely. Some shareware and freeware programs are HUGE!!!!!!! Maelstrom, Quagmire, and Digital Messiah are prime examples, several megs each. I don't know how to deal with magazines, but as far as internet downloading goes, people are used to spending a long time downloading mutli-Meg games. They do it all the time and as long that game and graphics are worth it, they don't mind. A cut-down version isn't too bad of an idea, but let's not make is exclusive to CD-ROMS. Let's make the game consist of jigsaw-like modules. If you don't want a 500k movie intro, don't dl it, if you do, dl it and put it in the same folder/directory as the programmer, problem solved. Another space and speed saver would be the option for 8-bit graphics instead of 24-bit. Enough people have 24-bit to justify it, but tons of people still use 256 colors, which works all right, actually. I use 256 colors without too much problem unless I'm using a paint program or something. Game graphics never bother me with 256 color graphics. Remember that we can define our own pallets so we can have 20 shades of red is we sacrifice a mish-mash of browns and yellows in one corner of the pallet. . . .. ... ..... ........ ............. ..................... .. ... ..... ....... ........... ............. ................. . .. .... ........ ................ ................................ /*Keith Wiley*/ * #define Electrogenetic Engineer * * * * * * Str255 residence = Univ. MD; *** ** * * ** * contact = email(keithw@wam.umd.edu); * ** ** *** > I`ve been thinking recently about how big this game is going to be (in terms of > disk space). I realise that now is far too early to be sure, but the way I see > it, our major ways of distributing the game are going to be via PD libraries, > magazine cover-disks, and over the internet. > > Now, I`m no expert, but if we`re going to need one disk (at least) full of > probes to begin the game, and one disk of program data, and another disk for our > opening movie, and then we`re going to put in extra movies when you go up a > level, or make a discovery, then we`re going to take up a lot of space. > > Who`s going to want to download 5Mb of data just to play the game? Who`s going > to agree to distribute 3 or 4 disks free with their magazine? > > It`s a bit of a problem. > > Perhaps we ought to think about a cut-down version (ie. without the flashy > intros and movies) for floppy disk distribution, and then a super version (with > all the extra probes, and video sequences we like) for CD rom users. > > What I guess I`m saying is that maybe we ought to decide now how much graphics > space we want to take up, and then we`ll know what we can and can`t achieve. > > > -- > Christian Darkin > > From dunx1.ocs.drexel.edu!st944m5h Sun Apr 30 16:11:34 1995 Return-Path: Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5i9D-000fJcC; Sun, 30 Apr 95 16:11 PDT Received: (st944m5h@localhost) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) id TAA11713 for ag-directors@krl.caltech.edu; Sun, 30 Apr 1995 19:11:09 -0400 From: Michael Mitchener Message-Id: <199504302311.TAA11713@dunx1.ocs.drexel.edu> Subject: problems... To: ag-directors@krl.caltech.edu Date: Sun, 30 Apr 1995 19:11:08 -0400 (EDT) X-Mailer: ELM [version 2.4 PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 960 Well, this has been a really bad weekend for me....my hard drive has slowly died. I was able to save all the server's files except range.zip, which was corrupted, so if that's still needed, could somebody please upload it (in a few days..) I expect the server to be offline for a few more days, and I won't have any real mail access until I figure out what's wrong with my mailer here.. (I'm doing this via telnet, and I'm totally unfamiliar with elm) the only other problem is that I've forgotten the passwords for the site also, so if someone wants to mail them to me, I'd appreciate it...(think it was director:gengame & member:belong??) about the size argument going on, 3-4 meg (compressed size)games aren't really that uncommon... and if this games going to be really good (it is :) I doubt we'd get many complaints, although it will make it less likely to be included in magazines..but maybe we could make a stripped-down version for that? Mike From undergrad.math.uwaterloo.ca!jmlait Sun Apr 30 17:36:00 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5jSv-000fJcC; Sun, 30 Apr 95 17:35 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57045-2>; Sun, 30 Apr 1995 20:35:23 -0400 Date: Sun, 30 Apr 1995 20:35:12 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Re: Universe Status Report (fwd) In-Reply-To: <199504291957.MAA08780@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 29 Apr 1995, Adrian Tymes wrote: > The size of the object's bounding box will be in object[].bboxside; FE > can read that. > > BTW, would it be feasable for FE to run a bitmap check if two objects' > bounding boxes overlap during the universe's collision detection? If not, > we're going to be stuck with bounding box collisions. > We could concievably provide a function for performing such a check that the universe code can use/not use. Probably a good idea to have it as an option so that those with slow computers can kill it. Bettwe yet, give the player the small advantage of only doing a bitmap check for collisions with the player. > > Shouldn't the table initialization take place before > > FE_InitSystem? That way, it doesn't need to be transferred to the front > > end & the FE can use the look up table. > > Like I typed, why not just put the table initialization into FE_InitSystem()? > sin() and cos() will be accessed every time something turns, so they > should be put into quickly accessable memory. > Well, the thing is sin & cos are used by many things other than FE, and I'd like to (for portabilities sake) keep FE as small as possible. As far as putting it into quickly accessable memory, if we're in pmode EVERYTHING is quickly accessible :> > > Okay, 1/5 by 1/5 would have to be broken up. Why the > > might? In order to avoid the usual problems of clipping, we're drawing to a virtual screen > > padded on each side by one tile. Currently, (And arbitrarily) the tile > > size is 32 bytes. By drawning an extra tile on each side, we can easily > > scroll & avoid any clipping worries. The latter is only possible if the > > ojects are at most one tile in size. (Clipping could be hacked in, but > > it wouldn't be fun (A bit of S-M :>) and would require about 64* the > > memory for a 32x32 object.) > > 1/10 is possibel as that's 32x32. Of course, we could increase > > tile size, bnut that increases mem req'ments and cpu load. > > I'm in favor of keeping maximum FE object size approx. = UN object size. > I'm also in favour of that becuase the FE won't like too large objects any :> > So, other directors, should we go for smaller objects or a faster update? > I think that if we want objects no larger than 1/10 of the screen, we'd > best give the player a 10 * 10 subsector view (and adjust the probes' > scanning range accordingly). This would mean that each subsector could > be treated as a tile, although their contents would change between > updates and some tiles could overlap the screen's edge. In addition, the > objects could overlap a tile's edge. > Interesting idea. The only trouble is then we have a playing area only 64x64 in size, which isn't very impressive. I think we should then increase the size. I do agree with having one sector = one tile, it would simplify many things. (Size of a tile depends on screen size, which is 10 tiles wide at the widest point and follows the 4:3 ratio) - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Sun Apr 30 17:41:31 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5jYH-000fJdC; Sun, 30 Apr 95 17:41 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57045-3>; Sun, 30 Apr 1995 20:41:14 -0400 Date: Sun, 30 Apr 1995 20:41:05 -0400 From: Jeff Lait To: Keith Wiley cc: Christian Darkin , ag-directors@alnilam.krl.caltech.edu, ag-art-sound@krl.caltech.edu Subject: Re: size of game In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 29 Apr 1995, Keith Wiley wrote: > Regarding the following post, I disagree completely. Some shareware and > freeware programs are HUGE!!!!!!! Maelstrom, Quagmire, and Digital > Messiah are prime examples, several megs each. I don't know how to deal Agreed. Large games pose no problems. Was the spread of DOOM hampered any by its enormous size??? > Another space and speed saver would be the option for 8-bit > graphics instead of 24-bit. Enough people have 24-bit to justify it, but > tons of people still use 256 colors, which works all right, actually. I > use 256 colors without too much problem unless I'm using a paint program > or something. Game graphics never bother me with 256 color graphics. > Remember that we can define our own pallets so we can have 20 shades of > red is we sacrifice a mish-mash of browns and yellows in one corner of > the pallet. > K I presume the movie palettes will be found via octree quantization spread over each cut. Adding in error diffusion & the results are impressive. (Fades, of course, are handled via palette). Another thing, as of now, internally ships are generated in 24 bit, but as far as the game itself, we're only working on an 8 bit version. Trust me, 24bit graphics at 320x200 is not worth the increased memory req'ments and speed penalties. 640x480 is simply unreasonable (A couple people have seen my 24bit 640x480 space invaders... runs at about 8 or so FPS, no? And flickers like mad?) We're probably going to have enough trouble getting it to run under 640x480x8bit, let alone tripling the bus load & ensuring no memory accesses are aligned (That hurts big...) As for movies, I've done 320x200x24bit movies, and IMHO it would be better to use a paletted mode & use the extra space to increase their length. - Jeff Lait (SOL) From wam.umd.edu!keithw Sun Apr 30 21:34:19 1995 Return-Path: Received: from pg2-srv.wam.umd.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5nBP-000fJcC; Sun, 30 Apr 95 21:34 PDT Received: from rac9.wam.umd.edu (keithw@rac9.wam.umd.edu [128.8.70.8]) by pg2-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id AAA12031; Mon, 1 May 1995 00:33:51 -0400 Received: (keithw@localhost) by rac9.wam.umd.edu (8.6.10/8.6.10) id AAA13595; Mon, 1 May 1995 00:33:50 -0400 Date: Mon, 1 May 1995 00:33:49 -0400 (EDT) From: Keith Wiley To: Jeff Lait cc: Christian Darkin , ag-directors@alnilam.krl.caltech.edu, ag-art-sound@krl.caltech.edu Subject: Re: size of game In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Another thing, as of now, internally ships are generated in 24 > bit, but as far as the game itself, we're only working on an 8 bit > version. Trust me, 24bit graphics at 320x200 is not worth the increased > memory req'ments and speed penalties. 640x480 is simply unreasonable (A > couple people have seen my 24bit 640x480 space invaders... runs at about > 8 or so FPS, no? And flickers like mad?) We're probably going to have > enough trouble getting it to run under 640x480x8bit, let alone tripling > the bus load & ensuring no memory accesses are aligned (That hurts big...) > As for movies, I've done 320x200x24bit movies, and IMHO it would > be better to use a paletted mode & use the extra space to increase their > length. ooooooo, we're not doing 320x200 are we? One of the hallmarks of Macintosh games is that they always use the monitor to the fullest instead of big fat DOS graphics (don't get me wrong, DOS games excell over Macintosh in several other areas). The sprites look sooooo much nicer in single pixel resolution. I would opt for doing the entire thing in 8-bit and keeping the sharp resolution. Except for movies. Movie files are always fatter resolution and I won't argue with that suggestion. . . .. ... ..... ........ ............. ..................... .. ... ..... ....... ........... ............. ................. . .. .... ........ ................ ................................ /*Keith Wiley*/ * #define Electrogenetic Engineer * * * * * * Str255 residence = Univ. MD; *** ** * * ** * contact = email(keithw@wam.umd.edu); * ** ** *** From post.demon.co.uk!darkin.demon.co.uk!Christian Sun Apr 30 23:27:27 1995 Return-Path: <@post.demon.co.uk:Christian@darkin.demon.co.uk> Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5ox1-000fJcC; Sun, 30 Apr 95 23:27 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id aa28269; 1 May 95 7:27 GMT-60:00 Received: from darkin.demon.co.uk by post.demon.co.uk id aa06474; 1 May 95 7:27 GMT-60:00 Date: Sun, 30 Apr 1995 13:52:50 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <154@darkin.demon.co.uk> To: Darkin@darkin.demon.co.uk, Christian@darkin.demon.co.uk, keithw@wam.umd.edu Cc: ag-directors@alnilam.krl.caltech.edu, ag-art-sound@krl.caltech.edu Subject: Re: Re: size of game X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 20 In your message dated Saturday 29, April 1995 you wrote : > Regarding the following post, I disagree completely. Some shareware and > freeware programs are HUGE!!!!!!! Maelstrom, Quagmire, and Digital > Messiah are prime examples, several megs each. I don't know how to deal > with magazines, but as far as internet downloading goes, people are used > to spending a long time downloading mutli-Meg games. They do it all the > time and as long that game and graphics are worth it, they don't mind. This may be true in the US where local calls are free. Everywhere else in the world, we pay by the second. I would have to see some really good reviews before I`d download *anything* that was more than about 500k. I think the reviewers know that which is probably why I`ve never even seen a review of Maelstrom, Quagmire, or Digital Messiah. All I`m saying is that we could risk being sidelined by vast numbers of people if we don`t at least offer the option of a cut down version. -- Christian Darkin From undergrad.math.uwaterloo.ca!jmlait Mon May 1 06:10:56 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5vFV-000fJdC; Mon, 1 May 95 06:10 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56878-3>; Mon, 1 May 1995 09:10:28 -0400 Date: Mon, 1 May 1995 09:10:22 -0400 From: Jeff Lait To: Keith Wiley cc: Christian Darkin , ag-directors@alnilam.krl.caltech.edu, ag-art-sound@krl.caltech.edu Subject: Re: size of game In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 1 May 1995, Keith Wiley wrote: > > ooooooo, we're not doing 320x200 are we? One of the hallmarks of > Macintosh games is that they always use the monitor to the fullest instead > of big fat DOS graphics (don't get me wrong, DOS games excell over > Macintosh in several other areas). The sprites look sooooo much nicer in > single pixel resolution. I would opt for doing the entire thing in 8-bit > and keeping the sharp resolution. Hey, resolution is platform independent. FE-PCX will be providing support for 320x200 & most likely 640x480. There's no reason why Macintosh has to follow those sizes. You can have that wierd 832xwhatever mode if you so desire. > > Except for movies. Movie files are always fatter resolution and I won't > argue with that suggestion. The raw movies will be produced at 640x480x24bit, whereupon each platform is responsible for converting to whatever format they desire. - Jeff Lait (SOL) From dunx1.ocs.drexel.edu!st944m5h Mon May 1 07:23:32 1995 Return-Path: Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s5wNk-000fJdC; Mon, 1 May 95 07:23 PDT Received: (st944m5h@localhost) by dunx1.ocs.drexel.edu (8.6.11/8.6.4) id KAA08478; Mon, 1 May 1995 10:22:53 -0400 From: Michael Mitchener Message-Id: <199505011422.KAA08478@dunx1.ocs.drexel.edu> Subject: Re: size of game To: jmlait@undergrad.math.uwaterloo.ca (Jeff Lait) Date: Mon, 1 May 1995 10:22:52 -0400 (EDT) Cc: ag-directors@krl.caltech.edu, art-sound@krl.caltech.edu In-Reply-To: from "Jeff Lait" at May 1, 95 09:10:22 am X-Mailer: ELM [version 2.4 PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 575 According to Jeff Lait: > Hey, resolution is platform independent. FE-PCX will be > providing support for 320x200 & most likely 640x480. There's no reason > why Macintosh has to follow those sizes. You can have that wierd > 832xwhatever mode if you so desire. > - Jeff Lait (SOL) I'm planning on allowing the user to set the size at certain preset levels, so they can adjust it as big, or if needed, as small as they would like it to be...all the images will need to be scaled anyway, so it won't add any extra processing time... Mike Mitchener From phil.ruu.nl!faassen Mon May 1 16:06:20 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s64Xh-000fJ3C; Mon, 1 May 95 16:06 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id BAA09589 for ; Tue, 2 May 1995 01:05:59 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id BAA05212 for ag-directors@alnilam.krl.caltech.edu; Tue, 2 May 1995 01:05:48 +0200 From: Martijn Faassen Message-Id: <199505012305.BAA05212@laurel.stud.phil.ruu.nl> Subject: Object size To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 2 May 1995 01:05:41 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1317 Smaller objects (like 1/10 of screen) sound large enough for me. Let's see, which object sizes do we need: >From small to large: bullet/small missile/tiny asteroid/small food pellet/small plant large missile/small asteroid/medium food pellet/medium plant probe/medium asteroid/large food pellet/large plant/dead probe boss probe/support ship/large asteroid Something like this. The boss probe size would then be 1/10th of the screen. I imagine this would have a lot of tiny probes, but at least we'll have a lot of overview then, and we don't have probes just zipping in and out of the screen too often. Plus, small probes take less memory. I don't think the radar needs to be so big..I just imagined it like 1 screen size outside the visible screen would be radar. This would mean that if 'S' is a full screen, and R is of the same size, but radar, the total range visible on radar would be: RRR RSR RRR This seems large enough for me, and less CPU intensive as well. Not only displaying the radar costs CPU time, also the probes *looking* at the radar costs time. (they will have access to all objects within radar range, at least the direction and speed info - if they look) Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From firga.sun.ac.za!9515291 Wed May 3 10:08:47 1995 Return-Path: <9515291@firga.sun.ac.za> Received: from oliver.sun.ac.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s6htZ-000fIyC; Wed, 3 May 95 10:07 PDT Received: from styx.sun.ac.za by oliver.sun.ac.za with smtp (Smail3.1.29.0 #2) id m0s6hCh-0015CeC; Wed, 3 May 95 18:23 EET Received: From SUN_FIRGA/WORKQUEUE by styx.sun.ac.za via Charon-4.0A-VROOM with IPX id 100.950503182414.448; 03 May 95 18:23:07 -0200 Message-ID: From: "G-J van Rooyen" <9515291@firga.sun.ac.za> Organization: University of Stellenbosch To: ag-directors@krl.caltech.edu Date: Wed, 3 May 1995 18:24:02 GMT+200 Subject: Re: Universe Status Report (fwd) X-Confirm-Reading-To: "G-J van Rooyen" <9515291@firga.sun.ac.za> X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail v3.22 On Thu, 27 Apr 1995, Jeff Lait wrote: > Another important issue: For speed, I am considering using > precompiled rotation functions, which would allow us to have 360 degree > resolution without the 90* memory requirements. The trouble is, we need > a different sized rotation function for each size image. At a quick > guess, we're looking at 10 or so bytes per pixel, so obviously we can't > have too many of these rotation functions. So, as I see it our optionns are: > 1) Tile the large ships, ie: make them out of many ships of a > given size. Give it to FE-PCX as if it were many ships. How do you plan to rotate a tiled ship? > 2) Have only a few fixed sized ships. Probably the better option. There's no reason why the ship size should be dynamic. Cheers G-J +-------------------------------------------------+ | 9515291@firga.sun.ac.za (Gert-Jan van Rooyen) | | University of Stellenbosch | | South Africa | +-------------------------------------------------+ From undergrad.math.uwaterloo.ca!jmlait Wed May 3 11:29:16 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s6jAf-000fIyC; Wed, 3 May 95 11:29 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57011-2>; Wed, 3 May 1995 14:28:37 -0400 Date: Wed, 3 May 1995 14:28:29 -0400 From: Jeff Lait To: G-J van Rooyen <9515291@firga.sun.ac.za> cc: ag-directors@krl.caltech.edu Subject: Re: Universe Status Report (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 3 May 1995, G-J van Rooyen wrote: > On Thu, 27 Apr 1995, Jeff Lait wrote: > > > Another important issue: For speed, I am considering using > > precompiled rotation functions, which would allow us to have 360 degree > > resolution without the 90* memory requirements. The trouble is, we need > > a different sized rotation function for each size image. At a quick > > guess, we're looking at 10 or so bytes per pixel, so obviously we can't > > have too many of these rotation functions. So, as I see it our optionns are: > > 1) Tile the large ships, ie: make them out of many ships of a > > given size. Give it to FE-PCX as if it were many ships. > > How do you plan to rotate a tiled ship? > Actually, tiled ships would ahve to be handled entirely from the universe end, ie: it keeps the tiles in position and orientated correctly. The FE code would just blithely assume they were n different ships. Provided there is non-zero overlap there shouldn't be any holes created by rounding errors. > > 2) Have only a few fixed sized ships. > > Probably the better option. There's no reason why the ship size should > be dynamic. > Agreed. Besides, there's no reason why we need more than 5 or so different sized shapes. > From firga.sun.ac.za!9515291 Tue May 9 11:56:05 1995 Return-Path: <9515291@firga.sun.ac.za> Received: from oliver.sun.ac.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s8uRf-000fJ3C; Tue, 9 May 95 11:55 PDT Received: from styx.sun.ac.za by oliver.sun.ac.za with smtp (Smail3.1.29.0 #2) id m0s8u5F-00159EC; Tue, 9 May 95 20:32 EET Received: From SUN_FIRGA/WORKQUEUE by styx.sun.ac.za via Charon-4.0A-VROOM with IPX id 100.950509203339.736; 09 May 95 20:33:49 -0200 Message-ID: From: "G-J van Rooyen" <9515291@firga.sun.ac.za> Organization: University of Stellenbosch To: ag-directors@krl.caltech.edu Date: Tue, 9 May 1995 20:33:23 GMT+200 Subject: Re: FAQ version 0.2 alpha Priority: normal X-mailer: Pegasus Mail v3.22 Here are my revisions. Mostly small grammatical thingies, no real major changes. > Project: Von-Neumann > > I) Game Concepts : Player's view (or - what is this game all about anyway?) > > Imagine yourself flying through a vast asteroid belt with alien creatures > on all sides; some of them predators with you as their prey. You must > drive to the heart of their realm and find a way to rid the universe of > their threat once and for all - you are the universes last hope. ^^^^^^^^^ universe's > > Sounds typical, eh? Fear not, there more to this game then that. The ^is > interface is standard for many shoot-em-up games - you have a ship in a > 2-D universe which you can move forward, backward, turn, fire, and other > normal abilities. > > What is not so standard is the fact that as you go up levels, your enemies > don't get stronger than you; they just get smarter! > > * they have approximately the same shielding you. > * on the average, they cause the same damage as you. > * travel at the same speed. > * see as far. > * turn as fast. > > - but things get harder! As your skill improves, so does your > opponents. When you develop a great new strategy, they develop > a great new counter move. When you learn to dodge, they learn > to follow. > > Furthermore your opponents are real creatures, with their own > agenda's, motives, weaknesses and needs. They aren't merely ^^^^^^^^ agendas > mindless brutes programmed only to hunt you down. > > Potentially you could even breed a domesticated strain to help > you ! > > All your opponentsare as powerful as you are, but they're only ^^^^ > trying to survive - killing you is only one of things which could > aid them in their goal. > > You survive only on their terms and adapt to their system - > otherwise you're just another dying breed. > [... snip ...] > > VI) How can the ships improve? > > Well, there are a couple of different ways. First, you can eat aliens and > strip their corpses to gain more energy (and ammo??? anything else?). Next > you can send some of the corpses back to a nearby supply ship for refitting > to give you extra lives later on. Of course you's only want to send the ^^^^^ you'd > best ships back for this since you want to be flying in something decent. > Finally you can send the ship all the way back to the lunar scientists who > will research the ships systems and be able to send you upgrades in > equipment for your own ship, as well as other technological breakthroughs. > > A complete list of technologies (once written) will be located at the ftp > site. > > --------------------------------------------- > > VII) What is the basic construction for the ALife engine? > > We've spent the past few months trying to come up with the perfect > construct to control these probes, but have only discovered that there > is no way to be sure of any of them without trying it. Some seem to ^^^ too > brittle to be mutated properly, others will take too long to mutate into > something useful, and still others just don't have the upward potential > that we want them to have. Then there are always the real-world problems > of speed, memory, and having programmers willing to put together these > horribly complex things. We finally settled on a three-phase approach: > [... snip ...] > --------------------------------------------- > > VIII) What were the other possible engines discussed? > > Neural-Networks: This would have been a very simple and straightforward model > where the inputs are whatever sensors we give the probes, and the outputs > are key-presses. The two problems (which led us to putting these on the back- > burner to be thought about more in the future) are that they are nearly > impossible to evolve (slight changes tend to break them) and its also quite > difficult to write an initial probe which works. > > Virtual Machine Code: This method was a close second for the probes control > engines. The advantages were that the method can be ensured to be Turing > complete and the landscape of possibilities could be made more fully > connected, but it was decided that the GP's stood more potential for getting > good evolution faster, and their possibly lesser upper limits would never be > reached. > > GP-instantiated VMC: I think most of us agree that this method has the most > potential. The way it works is that there are a series of commands (as in > vertual machine code), but each of these commands is actually a small GP. ^^^^^^^ virtual > The GP's would be made extremely versatile (although potentially brittle) so > that commands could be made which could do anything, but most of the evolution > would (probably) take place on the level of the VMC. This method gives the > best of both worlds to the evolution of the probes, but unfortunately the > worst of both worlds to the programmers (and maybe the CPU depending on how > its done). > > Brain-in-a-Box: An early plan was that loosing players would have the ^^^^^^^ losing > tops of their heads sawn off and their brains extracted and kept alive in > a nutrient tank, permanently plugged into the game. These brains would > then provide a "human strategy database" of subroutines for seeding new > aliens. The idea was rejected on some obscure legal grounds in certain > countries we want to have the game releasable in. :-)) [... snip ...] > ------------------------------------------------------ > > XII) Who is running this project anyway? > > There are 8 of us who (as I mentioned before) are nominally in charge of > the game. To the best of my knowledge the directors positions have only > added responcibility, but these are the people who keep the game going. > In general all participants in a debate have equal influence, and the only > power of a director is to break a deadlock if it lasts too long. (Heck, > both of the directors of the alife group wanted an engine other then the > one we finallly went for :-) ) > > Greg Taylor (gtaylor@galaxy.csc.calpoly.edu) - The head of the project, and > 'director' of the ag-directors group. > > Charles Ofria (charles@krl.caltech.edu) - Co-Director of ag-alife group, and > maintainer of the ftp/web site and this FAQ. > > Martijn Faassen (faassen@phil.ruu.nl) - Co-Director of the ag-alife group. > > Adrian Tymes (uwingcat@mcl.mcl.ucsb.edu) - Director of the ag-universe group. > > Jeff Lait (jmlait@undergrad.math.waterloo.ca) Director of the ag-pcx and > ag-art-sound groups. > > Mike Mitchener (st944m5h@post.drexel.edu) Director of the ag-mac group. > > Christian Darkin (Christian@darkin.demon.co.uk) Director of the publicty > aspects of the game (no associated mailing list, unless there becomes a call > for one). > > Gert-Jan van Rooyen (9515291@firga.sun.ac.za) ??? Sub-director of ag-pcx and (possibly :) ag-art-sound. [... snip ...] Cheers G-J +-------------------------------------------------+ | 9515291@firga.sun.ac.za (Gert-Jan van Rooyen) | | University of Stellenbosch | | South Africa | +-------------------------------------------------+ From mcl.ucsb.edu!uwingcat Tue May 9 16:37:39 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s8yqN-000fJ6C; Tue, 9 May 95 16:37 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id QAA19341; Tue, 9 May 1995 16:36:49 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id QAA09408; Tue, 9 May 1995 16:36:49 -0700 Message-Id: <199505092336.QAA09408@mcl.mcl.ucsb.edu> Subject: Object Structure (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 9 May 1995 16:36:49 -0700 (PDT) Cc: ag-universe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6627 I think that we may have to shuffle the order of the elements around to satisfy FE, and weren't there some AS variables in here? (Thus the copy to ag-directors...) > /* May 9 '95 - new object structure for use by Universe > includes very extensive commenting on design > by Martijn Faassen */ > > /* standard object */ > > typedef struct > { > unsigned char what; /* what the object is: > PLAYER - player > PROBE - probe > ASTEROID - asteroid > UF_EGG - unfertilized egg > F_EGG - fertilized egg > D_EGG - dead egg > D_PLAYER - dead player > D_PROBE - dead probe > SUPPLY - supply ship > D_SUPPLY - dead supply ship > UNMOVABLE - unmovable object > SPECIAL - special object > */ > > short x, y; /* location of object */ > short velx, vely; /* movement vector */ x,y,velx,vely should all be unsigned long, and should probably be shifted to the start of each object. > unsigned char facdir; /* facing direction 0..255 > PLAYER > PROBE > SUPPLY > BULLET > MISSILE: for navigation > PLAYER > PROBE > SUPPLY?: for firing > every object: for animations, for example > after a collision objects may turn */ Ojects don't currently turn after a collision...do we want that? It could confuse the probes. > short mass; /* mass of object > PLAYER > PROBE > SUPPLY > BULLET > MISSILE: thrust needs this > every object: collision needs this */ > unsigned short bboxside; /* length of side of bounding box > every object: collision needs this */ Maybe also a pointer to a bitmap for a FE-implemented bitmap collision detection? > short shield; /* shield of object > every object: if shield <= 0 object dies > What happens upon death: > PLAYER -> D_PLAYER > PROBE -> D_PROBE > ASTEROID -> breaks into smaller asteroids or vanishes > UF_EGG -> D_EGG > F_EGG -> D_EGG > D_EGG -> vanishes > D_PLAYER -> vanishes > D_PROBE -> vanishes > SUPPLY -> D_SUPPLY > D_SUPPLY -> vanishes > UNMOVABLE -> vanishes (or may be indestructable? or may > turn into special moving object?) > SPECIAL -> depends on what we do with this :) > */ How do we handle this? Do we want a UN_Die() function? > short energy; /* energy of object, can be used for navigation/firing by > animate objects, and is used to denote nutricious value > for inanimate objects */ > PLAYER > PROBE > BULLET > MISSILE > SUPPLY: used for thrust > PLAYER > PROBE > SUPPLY(?): for firing weapons > PLAYER > PROBE: to lay an egg, and to fertilize an egg > UF_EGG: energy may decay slowly > nutricious value > F_EGG: energy is invested in properties > nutricious value > D_PLAYER > D_PROBE > D_SUPPLY > D_EGG > ASTEROID > UNMOVABLE: nutricious value > */ > short age; /* - probes may use age to base actions on > - eggs can hatch at a certain time after fertilisation > - certain weapons may explode after a certain time > - nutricious value (energy) of dead objects may degenerate > with age > - statistical purposes */ Maybe we can also add a "time in current probe" readout on the player's view? I don't know what the players would do with it...or perhaps we can play the different movies at some pre-set time after a specific event, using the player's age as a counter? > /* possibly: pointer to sector object is in */ See below. > /* pointer to extra non generic object information */ > union > { > animate *aninfo; /* extra info only used by PLAYER, PROBE, and SUPPLY */ > bullet *bulletinfo; /* extra info only used by bullets */ > missile *missileinfo; /* extra info only used by missiles */ > special *specialinfo; /* extra info only used by special objects */ > } extra; It would probably be faster to have these be the structures themselves, rather than pointers to them. It would take a bit of extra memory if there is a difference between the sizes of animate,bullet,missile,and special, but the speed gain would be worth it, right? > object *next_hash; /* pointer to next object in list */ > object **prev_hash; /* pointer to previous object in list */ Under the current universe.c implementation, the first object in each sector list has its prev_hash pointing to the start of the sector list. Thus: sector-------+ ^ | | V prev_hash<--object > } object; > > /* extra information used by animate objects */ What extra pointers do we need? > typedef struct > { > object *target; /* target */ > short thrust; /* thrust power of object */ > short turn; /* turn speed of object */ > genotype *gtype; /* pointer to genotype of object - alife stuff */ > weapon *wlist; /* pointer to the first weapon in the weapon list of > this object - system needs to be refined later */ > action actions; /* virtual keypresses done by this probe */ > } animate; > > /* weapon stuff needs to be worked on, > depending on the evolable weapon traits we design. > BULLETs are weapons which are not remote controlled by the probe, > though they may be controlled by some standard program > MISSILEs are weapon objects which are remote controlled by the > probe */ > > -- > Martijn Faassen email:faassen@phil.ruu.nl > From mcl.ucsb.edu!uwingcat Tue May 9 16:40:12 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s8yso-000fJ7C; Tue, 9 May 95 16:40 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id QAA19570 for ; Tue, 9 May 1995 16:39:20 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id QAA10313; Tue, 9 May 1995 16:39:20 -0700 Message-Id: <199505092339.QAA10313@mcl.mcl.ucsb.edu> Subject: Re: FAQ version 0.2 alpha (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 9 May 1995 16:39:20 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 385 I just caught one more error: > > Project: Von-Neumann > > > > I) Game Concepts : Player's view (or - what is this game all about anyway?) > > > > Imagine yourself flying through a vast asteroid belt with alien creatures Note: the probes are not aliens. They're barely extraterrestrial. The probes have descended from a human-made probe...are there any aliens left in the game? From charles Wed May 10 11:25:55 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s9GSH-000fJ8C; Wed, 10 May 95 11:25 PDT Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA19943; Wed, 10 May 1995 11:25:21 -0700 Message-Id: <9505101825.AA19943@rigel.krl.caltech.edu> Subject: More on web stuff... To: ag-directors Date: Wed, 10 May 1995 11:25:20 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2773 Greetings, As most of you probably can tell, I've been buisily working away learning html and putting the web site togeather. Please send me any comments you have on it (especially spelling or gramatical mistakes). Obviously 95% of it was direct from the FAQ, but I want to build it up quite a bit more - there are quite a number of areas which need to be fleshed out. Anyway, I'd like to try to get this done as soon as possible so we can advirtise the web site on the net; now that we have shown we are serious and know what we are doing, I'm willing to bet that we can attract quite a number of more people. I think the main place we need them is in the FE groups (and it would be great if we could get enough volunteers on other platforms to create more). (SIDE NOTE: Should I create an ag-fe group to bounce to all the fe groups? And people interested in the front-end in general, but not on a specific platform...) So now I want to push to really get things going, so I'll ask each of you do do something for it (No real rush on these things, but I'd like to get pointed in a good direction). Greg: Can you write up a brief statement of purpose for the group including things like plans to have a professional quality freeware game and whatnot. Oh, and of course figure out if I'm missing anything that the FAQ is missing. Martijn: Can you write up a summery of the pre-game plot, during game plot, and end-game plot? The last two I guess will go up for debate. Just a paragraph on each I guess... Adrian: Could you go over the glossary and fill out any game specific terms I might be missing? I'll also ask Keith Weily (who volunteered to do this previously) to do the ALife side. Gert-Jan and Mike: If there is any front-end stuff you think should be in the web page, please write it up (I would like to get some more technical aspects there for those interested) Jeff: The art-sound group definatly needs a page, but I have no idea what you are doing. If you could send me an outline for a page, I'll put it in. Christian: Hmmm... I don't think we need much on the 'buisness' end of things just now (although I suppose when we do get the FAQ done, well send you out to make sure the world knows about it :-) ) Would you be interested in writing something up on evolving bullets? Oh, and see if you can track down any other relevent links for me (not important for the moment at all). I think thats everyone... And with all this we should be able to start recruiting... Yea. :-) Of course if you don't have time for something, just tell me and either I'll do it, or I'll find someone else to. Not a big deal at all. Finally, please send me any suggestions for improvment! Thanx... --- Charles From firga.sun.ac.za!9515291 Thu May 11 02:21:52 1995 Return-Path: <9515291@firga.sun.ac.za> Received: from oliver.sun.ac.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s9URF-000fJ8C; Thu, 11 May 95 02:21 PDT Received: from styx.sun.ac.za by oliver.sun.ac.za with smtp (Smail3.1.29.0 #2) id m0s9U3J-00159CC; Thu, 11 May 95 10:57 EET Received: From SUN_FIRGA/WORKQUEUE by styx.sun.ac.za via Charon-4.0A-VROOM with IPX id 100.950511105513.384; 11 May 95 10:58:23 -0200 Message-ID: From: "G-J van Rooyen" <9515291@firga.sun.ac.za> Organization: University of Stellenbosch To: ag-directors@krl.caltech.edu Date: Thu, 11 May 1995 10:54:53 GMT+200 Subject: Re: More on web stuff... Priority: normal X-mailer: Pegasus Mail v3.22 On Wed, 10 May 1995 Splinterwood wrote: > As most of you probably can tell, I've been buisily working away > learning html and putting the web site togeather. Please send me any > comments you have on it (especially spelling or gramatical mistakes). OK, here goes... On the first page: Von-Neumann --> Von Neumann Glossery --> Glossary Players --> Player's so does your opponents --> so do your opponents Their will --> There will sophisticated and ecosystem --> sophisticated an ecosystem it comes time --> it becomes time The link grinded to a crawl before I could finish reading the other pages, but I'll send my revisions of them shortly. It looks impressive, though! Cheers G-J +-------------------------------------------------+ | 9515291@firga.sun.ac.za (Gert-Jan van Rooyen) | | University of Stellenbosch | | South Africa | +-------------------------------------------------+ From undergrad.math.uwaterloo.ca!jmlait Thu May 11 08:36:16 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s9aHd-000fJBC; Thu, 11 May 95 08:36 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57026-1>; Thu, 11 May 1995 11:34:59 -0400 Date: Thu, 11 May 1995 11:34:55 -0400 From: Jeff Lait To: Splinterwood cc: ag-directors@krl.caltech.edu Subject: Re: More on web stuff... In-Reply-To: <9505101825.AA19943@rigel.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (SIDE NOTE: Should I create > an ag-fe group to bounce to all the fe groups? And people interested in > the front-end in general, but not on a specific platform...) This would be probably a good idea, in this way the different platforms can ensure neither treds down a path which is too hardware specific... - Jeff Lait (SOL) From charles Thu May 11 12:21:59 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0s9do5-000fJNC; Thu, 11 May 95 12:21 PDT Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA21397; Thu, 11 May 1995 12:21:21 -0700 Message-Id: <9505111921.AA21397@rigel.krl.caltech.edu> Subject: Update on web page... To: ag-directors Date: Thu, 11 May 1995 12:21:20 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 683 Greetings, I've made a bunch of modifications to the web page thanks to things people have sent me: The intro page now contains just the statement of purpose by Greg (The actually introduction was given its own page) A summery of the story so far is now included with a pointer to the full script (thanx to Martijn) Gert-Jan sent me a list of typos (and blatent spelling and grammar errors) which are now all corrected Keith Weily sent me some updates for the glossary which have been incorporated. Hmmm... I'm sure I'm missing some things (and I'll have to just appologize for that now), but in generally the pages are shaping up nicely! --- Charles From undergrad.math.uwaterloo.ca!jmlait Mon May 22 11:53:09 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDcan-000fJ9C; Mon, 22 May 95 11:52 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57030-3>; Mon, 22 May 1995 14:50:57 -0400 Date: Mon, 22 May 1995 14:50:24 -0400 From: Jeff Lait To: FE-PCX , Directors Subject: New: POC III, part I Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is POC III uuencoded. To thrust, up arrow, turn left/right, guess. Stop, down arrow. Esc will quit. Probably have a few bugs left - look at evilutio.doc for more details. section 1 of uuencode 5.20 of file poc3.zip by R.E.M. begin 644 poc3.zip M4$L#!!0````(``D)MAZKS*&?!!$``*0Z```)````1D5!4TTN05--W3MK<]LX MDI^5JOR!^]3Y,GDQ.E&R95O>G9QC.8EOD]AG.9-D4ZD41$(B8HK@`I`ES:\_ M=`-\2;)G=DNINENG')-X-!J-[D:_>/QL%S\/'QS#Z[.3T?NV_;4OK>M$:(AD M9IC(-)B$@^V`R3R+C)"V1?%_S(7B,8Q7=N+EZ>&4KY28)@;"HZ-] MQ/B_^60"[Y@P[6+,)50;',;FRB(\5Y!N/Y9,() M]RA!:'8KMC$5!DDA[3)P*QB\L@TCFN`I=P*_G8U.2C06PBZ2*SEF8[OL7'/( MV93#)!5Y+K*I73*VR-11B87BD4E7",X"\-A8ZBH>SR-N-Y'%"Q&;I-UN%_NW M1R!F%B.AL\<&5MQ`(N4-<=(.F0?_M5KMWF$_Q\<="EHA18/=0>9,-];+3MX&<`JM<2)4S!LX@P M.X;>03_\4\`M(:ZD8>8^T/C\C,=3'C/#U@"\E[=\9)C2)7%H/CYD\YG&'GIY MAH];YN-Y-N=KSF.WI@7@%W<3'S[X/CRY/K$CIC/4*#E3##RTN>9VCX^Q__%N M9>#L?SZ>7)^-=@=R='EU?GWV"?YJ#Z9X>^O??CN_NL:>T#]C^U$Q:/1W[.ET M]W:[0:39[N`5H@C#(;Q\^&#I1-2_K1IO%VG\-[ZZF$P:[R,^A>$G?+]B62QG MV!EV>WO[_8/#Q.FZW>W]_3PU(D]%Q%#-@4.O#?"6KP*\6!2'V5P;&'-@]C]C M\.)A*]3Z4YYQQ0QWMZG8L"->P$FV`CV?3KDF'?KRY&,!?.D$8=(->L!?L!_W@(#@,CH+0-H9!V`W" M7A#N!>%^$/:#\"`(#X/P*.AV@JZ=TPVZO:"[%W3W@VX_Z!X$W<.@>Q3T.D$O M_/7A@Y9?HTMK@%W*/O4"V`M@/X!^``/4'4GAW!K=,<'HQ/-OE9?S]^NSS]7U:"A=\C"1@6L]G'"(] MH#D!Q/8)=QD`]T\[YO>3TZN+'>JR7>)V?77R8?3]_<5O>!BM(1F"[M:R).1T M[=YRF"@Y\S<3,CC>-FCT[L%X9;C>H5%5H>.HMF8AM"PVP-DR@*^NZ5O1%MLV MVV%?]7P,<1I`B,]C]QRG**XC;F#X#C<0,:56[6)P4AMLG^/$OBB9.J!A'\F$ M5L8">H?]QTZFCUMCO6`Y#D'(KYDV7`4PGALR41<:Q^KVG>C\^:6KA6P7VL?4 M]17I@IN7RM'#]2,I7)>G1B'%.[1./WXXO3Z_^/!_E)_=]37D*=HNQX!GKN'L MY#.>.@/E+K<8N\E=(&?)7RH2%;@&)?*.<5HBB[Q$T,RQ M$Q#DUFN9VR&>&,3._Q0HMWXI;C1^W!A?HNIVD]OU[)/;'_&IXJ9)"I[%N_:B M&EX$O(!3EJ;V7#'2@&)UNS;B2>%C/#W&;OP!9!SBDE?#`;QG-]QYL^@7I()E M9H>*;\WI*7@#D0H[24&R]5$_BVSH(-Q-,NQ]XER?9>$#E5ZA>RT,TI*81$O[ M]VQ(_[_ZO&O2D8]:D`T9<%E@5'%NB62E+0M$/:\>PXC=@);!L)3,. M$%QR/4+'MTC7):+#$A3!4\69X7"2"D:W!)YS M+\1SMA@D9VT99!+G6D:]<& MEJ3-Y`+9A889$=UP!;^`XK20H0`KCYWV;YP4TEV+IL9QPO73E+0/&-VCI/V( M)Z1/=K3\6K2J>1VS9?U*!HQ$ZOJ)E=SC&V,=5%RV[:R;Q^>/P;8E+(M37CM! M7*MV6WJ&JZO_$N/R0.#C-%TY\W,AU0U*$LF]]^EW>63GGJU+S/4`X-*B9U:H M0";`;T7,=WHWHEC<>SI$-$3NC24JAJT*/[#09(ST\*"N"^-"87II:^I#!*11 MZ:,R@U\HU:%D.JBS0+_CSI6@TX6R[09([3+.^\"+I82)Y[V,DJGMM`,29\GC M\V$G*>3[AJ_&DJD86'23R46*T4`GL&B0T8K2GCCBXI8XJ<;AY%QQK1_940;] MM;$';H]0@S"@>,J9YB]M_X_L=_@[5_(T88I%]GS)38Z]75?3@K2E5U^NS^#R M^@J^VNYO`82D\_#:%QIH31XCDJT?LQQ&-R(/]WKVM;'`@%;(8L+J8)+\4PMV M;(>'._!.$7-@2+:N2+8*XK4;5"KXP0[O=A*O2>U\<@%$!&<7Y^@I7)Z?%O/L M,#_1L06F`5)I79FS5:CT.--U+5Z-\-9C%?5>N#])97RWR&#$ MW-O9\#/](9L1X+5(4XU)00;CE$4W@`DBEDU3#A'/#"8=61%0EQ-8+!.(Q6S& M,\Q`[3)6L9%,:>HHX@]1-R<9SL?&PUW'!\;T`#@,(NQBKP%O`_MJFK@N/MVH!R*]VZ><)R+JWF61X1KZY5B4(3821S*P'K%[NM6]@:1?A;/5WG3BMV]R0UP MNS'H3F:OLJO$]G#'#X;?RN=A[7GW48!:1G@;BWD5L\97V[B.3/=.I]6J\]B, MQ;PP%5`SD@KK[@\:2O*P4^A(V^1T9,DE7@>2.F2E.O1@ZH[8-O:H[^UG!GXH M,_QD(RN,N62?&2[2RG><>OV\MYTX^!"B^)UKR*46KF;H%^>24CD-5H!0'GOG M]W65^_XC!HD:8?7:^97'>;@U(EK=;D==8@V4L&9@NN6NXKBZ4\MX2S,[U]_? M[_6)9<1MP3T4Y+?K?PM<^J%U#)__I67>_JEEGN\5"QW#E[O6H<0$Q;=Z$_N3 M-``RL[)>]4D)8$3^NIH;=:NZI3.6<'.7J!-QPDJ=HBWEQU/TC MH:JQP\^2J;):XTFSTN-?E:FZ0-6E"M>`UU+-F/&E8&\YB[D:8#(__AQ`_,4U MGZ6#R;F:\`BM`S0X1(J6!R)*C@DI1'WCBOP8 MI'8Q[)<9IT@$I>@EL%LIO*.S(#UJ,(YN%A)RIC77OJ3,]96E89FD]/]"*I.` MK\/#;+O%G&Q_C,,/X&^<+%%+6FS3/*?:`*P)N]$#.%52:RQ-TZ!+%6X2)1>9 M]N5D#*)B$,*);JAT)^:,=DI%B6QBN%K8L]F]*JK*>.Y21<#'^7WW53-95%-6 M*.*D(T@]Q)_+]CPHA)HZOJRK,_39472NN3;=_GY#G?7[U4T7+RM`7B]4N5FW ML%=+E1O3;PI^OR'X7^V8NUP7"^K"MJO"_L`7$'\A!.LZVP4;7E'9+&J8".,+J@UO M+%X:.B_"?KO"KCKM[8H=UX@JY>YWZZ[.67[O[GZ,/7$.'(;D"/_[$>-@<,?% M3T'%SYZ#T,=[O.F+U.=Y,1"]/B[?]W MVMO=;3+BEMUY1NR%X28C_OL0(PP;C%B8AH[Y/E'96V:GD69EIJQ"+Y1L\X;8 M=I?LZ,+8!&UW=M^%014YF`<5F=#)8-/&K-V)@WM-SGZ_K'BXQ^RL7?T_+;!5 M+V'>\/.KP%9]V)J%NEGFW+1.76+?6:,VP,<1E9") M[%;><+Q>2Q0IU1)18CS&KPE<0L?5>XYR9*Y33)P`P?4EGFA\\HCAEP1R@M]C M2+7"9(U&NP\%-XK&[PMQW1E[(+502T=O M#1,UE_F9@5%?I7X/]U2#[N"=M3KV>G#?%X/X:A#PQ8=:8'4-??EC7LQ8CK'* MN49[O,XLE.-"D+Z,"XN&<2SZ`D92Z)0^7QFOT"'QE0E<8'4Q^@HT7BK_;1&" M*`&"7T.Y0H4=476S\O]^F]]5@G",9@[*9SL#J8%$%AD53P_NX"BG(,=+9YZ_ MI:\ZBI0"6T\I_$'6H-2XM?Q%`9_LBD_X[<@Z]"J90;.*S7B^&&RR?CE"9)$B M!U77T[>TFY"BK]$BYG6'QE]8;^TF(5XN&Z46-*V/1'@G60P)CL'T,?EV*:;8 MI&YO+-/#"2R!O^(0FH.%KN1]8+4+2VT/-=ON=IDPSIDVD)#/W2X(-2XNKG)[ M*RQXS^&6J7)_Y+WARB_";G5>Q-DG"M,PKDZ1Y@G\)DI/Y\@"4U2K&9],1"0P MY4YF8"WZT6DD=1R3N=1E%=;41CI1&+UXCW^TG'&3H+CQ5/-FM(5._&$]Q$WD M.OS6"(`Z$G;7+V''C)A^SH01EH033`533LZ9KVO9\]:/:/D[G&5QSX6(JGT= MN"N80&5<$5T&<*U(U#%P88FB9(H^?`!CVQNOR)<;_*6T=L:)MPL*'K:33MZ< MPPMX>X+_'CUZU#1J?;C6-D2%[YU3@T4:@8V=L?;C=^>/''1<2M992C&:['Z$ M[QXT4(E=']59NEQ:W MD(;U1)AH*6JX_MC*::B[XI["3PF`*N_I^>&#__A?4$L#!!0````(`*ILM1Z& M@J'E(`$```0#```'````1D5!4TTN2(623T_S,`S&[Y7Z!3A9VV5,2+O#">B& M.$Q"=/?)-"Z-VL8A@@Y`Q, M'B?P"3O6"GKB-G.XSS\".IH5%3J8*_)R`]H([.-17=_!UV7`L]$RZ^KFAX:Y M#C9VS8\_4<36=!1\:V@8EE=!,MZ;V7!99WKCT/BS\T[PU[?GX(HQ(9(GA[;J M6UM6(^4/C9:\<$3FORG%>]0[:]?:CGCG%T<%MU8WI`9H,2I&K76S>&5!&:3U M7T+JG10*#@/7O*-R:-4[JUB)1^+$3J,F-*1NDR3:Z^`5!+`P04 M````"`!R`-*:5[Q143B%I3&CL^&+_)BF1Q22/PSF<#@+CVG_[/Q.,SF=%6]\8+! M5>C8K.3O#`:AG9;WNU1Z-15BCD&B&\+FS M#@38+]R@V^K6&QQ&1&G7GE)9I1-?"OVQP734^7IK0Q\1Z\RN=O`Z?:8/#'XB M_QQDQ:JF:B%S^ M`5!+`P04````"`!M>Z4>:=#=G-@```!4`0``!````$9%+DA-D$MNPC`0AO=( M7*"K$5V41A$"3C-!K8U M],@[O#N*:V4[AD)Y9^CX_/(?MC9%[2]N/3?SHE6,.-G3=O0K_Q.HQS8P1;PA MQ2=6F&ODXG4LGSA,X0F'.?8;-7>7&_CK]:.N]E`88HDEW.7@4PEB/4!?`%7QX(NI-/0M)5: M"+32"O)J%*H+(9MI3V=9!E(2+M)JE5$.E?@!SEBO5ZIYC MQ\R$9Q9SKD.9!,]@>1N,W`[8>P8F-:UX"A:Y8,D,K+,`FVHODLN#Q%_Q_H+V M3UC77PU:4?5;%Y?9DTYM:^=MJE/X_DW[)_E":,(&*IXWX0]N1IM)N<25HC3Z MO'5U/<:&M;[EJJ^;2F>9<"S2.2:/$YB@#4$L#!!0````(`%VYI!YL+%^O0````%X````+```` M159)3%5424\N34LK*,K/2DTN4;!22+6*22W+S"DMRK*^A(``(Q*```)````1D5/3$0N0U!0[3QKJW*&;Y*R M%2]I*>7X$?DN<5R1LY96ITJ!,Z"(U7#`!88B)[>^WW[H!C`/:40_ELI=75EE M4T.@N]'H%QH-C/JM'?S/7RIV>OW^#CKB@"O)L+#>8?BV-(Y]R,T7W[ M_`1"&7%8ST4XAY`EH%-A^J>F28DTY0F(!)Y#M.)$)94@TF\TQ"R\!#F#A/,( M9E*!7N+3=)4Z`HN53I'*JY?F,V0KS0VB&9VHB,4RY@N>I"P5,D'<4,Q$V-O1 M?/OW[]V_]V\B">.5F=K3A9FP#'OSPTHC7U1;_CSC3)NV/S<:_3X\TPN8K9)0 MY\SAU-.YT+TJ#B$@QG'*DHBI"&<\YRSBJ@*Y2L055YK@#?1S:28O$@T_?__O M+Y^_@XC/1")0&CUDWD"\FW/-;3O7L$:9SMD51S:F'!9F`+C@"5_O'L/`,-K;4>-OUQ'//Y;8S@8/2J:%VP3L,ZT M"4'`GII?WT%@/L<0L&:S!"62'.KP5B@VU:;!,&*@X"D,"*Z+,#=`W_[\^LV[ MWUZ_"38=R#JP[L"\"?]Y_UXC"#9PB*@/'X)Y?`IK^Y@5K9EIG2.Q^_=VZ*(B MYO!7I@2;QER/=V>[(DFAM8FEO%PM.]#*[-/D_KUPSA1<\BS%$<^&HR?GOC%5 M+-$WFUM70J4Z5)PG$Z+;@!>F)3M.67AY]G@X.I^@,?XD%8=TSA+@B5Q=S'LW M8-]*;0D`_,(CQ=;/XOA5S"[@``9^L`5;TN!5#E(1KQ?-"F9LI3;-G(= M\P1+Q4.Y6!KH"`@``P.&)MUS`SN\B*7,X1K4E]$%!VRB(%1!-'@-^C%@KZ1: ML'0,1^288UB+*)WWYUQ("R MIDEU`!^]C/"9)1-`&A&Z]>/CO^Z;<7 MBJV/23Z!958,V^WS#I2^H/@;R$^)2^N_ELE=9B^_O>,ZQ>?&"\DU,`CGG"TA MY>0[SE&3"V!3$8LTVZ%ADZ@=`X'3]EPLRV9HQ5Q8A14U/J%&;7L3!ALV,#\3 MW]4^@.%@T-H;#5#Y^]3A9"_?%M$KL'9FQW2ACH8E^??[)7W]8@-:#08%.8\% M_7Y=\YVH[74BK-K>S3F$,IF)"YCA0I=@!(WC#-;DM2F/8UAI6,]9"HIKX&G8 M`XRS!G+=(7)K#DSKU8+#WFBP&0T&.\SOO):17ZM$#G#O1 MPO#ZPDR,]WJX6&!:ICA+.>"*"ZLET(JJ;:];D)W/HX'8O#+`[,C,5HO?N9Q1 M/"#=9+?!?[O_I`8<>7P0>*1__A/<>$WGY;C6*26580;@/7=9-J7?H5PL9`(< MNP$-\8JK[('W=5S]$-3.90P0^'U`(E,(5TKQ)(TS6&E#:I48LJBXB(K`H`/#T1/"Q82>IS:O MBFU.04"8?@^[0PBE,L26,HEX$O(>V!P*H5"X!H/2_SIYC:JS*F5N;F)HS4UK MN_D4GJ'EH&5B0K=B,=BD#F=1I'CEX.5LS:?PT'(IO_U]1'-T\R\(D`2VHAA6 M_*J/&9N+2I1NC6WW&YGRL=U3INR2:W@$BRD\!)G$&:WJ\.VC?7CU]MA[G%Q@ MEF6(R%5:VBI^HT''X',/WB;O:-5X'B^ M2B.Y3F@E>*4XU[#@"ZDR,[*(8PU7/$RETG<0T/W005T@MS(YYND/BBWGP6"S M1P*8&0Z]D(J&['I#8>BV[:-F15B%;146X_@PK+X@5N]N+3XF?DD/9MK:YL+6 MV_VJ>S>+JATX<+G2#<$/K>1+ZTN$FT6;;L):I'/@22H4+T6JZSO'X=V([;E- MQ*S[^](7A2*&T7>#_T>/]T,(WD@(92Q7*E_P9S9_Z?5Z35>H8A<<'F(F=,55 MJG%KDDI`%+G&TEC*58+A6/S.=Z@(&\6OSR6HV;N4MS:ME"^6$^LR#0`Q[(`8 MU>>VE>4!0[P+3$4J@A@^NO)TI1+*4@L7P+$,1;]!NNE,CF+5H0AJY*!&.=1[ M_)9#-6@B[;8!:Q4[JT;#/F,>_L@V(!^EUN'H26N/J@(7G-24\$T*L4A<\D+P MUR=S!VZK_X-G-H?F&"O7B:C-7&`V8K'J#X/U9F8CRR"3A+(MQWA8:(F&&!)RW! MUHZ^NP*6%T3@BU;.8)W\\RI6*?\Q;>=WM:^QL:<432D)1AEDUE:F'&8B8;'X MG4>](F#$(KGDD?EE]ZUR^G<>8AB61%AQ%D'P+(D,I&*DY27^2D7H0$N%71I% MRK2Y^X!=GEW@*LJMF5`8%?S73*YPCRE5BD6Y\%*7J@W)20>2TTX1,JA5SF:; M#GYFOJ6H&W;`UP5]"0&#CH\&?LQPI5SU!"5"-$\,?-<,(T_IP88G6D.(VS#F M3)77$EPX?.&DJ$=VX&&E.%E9C)(($KZ&U7+)%<1\EN;;.U*Z/YD(YRRYX!&J MA86A7+`($T`64G[]JRO7DZ]8Y.`]G9%@Y@<.3K9#8BIHM*IX<'A'A&N6QA0@:BXIE5EQ&UM8.CBMU/Z5DD)BIWN0E[5;76(7!T*XMCV:M8! M`5*BB126=OJ5C>2?'5M:S3RBJ6W9&_$ M'7`0C<;#(E<]$\.6WY.UK"K;AJ)K>W_>R9'`UMJQ#B]/VV)X?B9/VF+D8FK# M+YC^E_>JZVPT2XLKCS4O1/Q"`H,E4ZE@,2@2HEM9O6D\A>3$S-0>B(5*8MU! M6A^T0Z_G6$PJ@3K.:">XS+S>JDBX4PV7666G6I;035&0G$A:1[GPH.M=,9=' M838*2]6T^QN[/I\R49VA/)JE7;BL']T3+8Q%GCIKD:?0KC69K=:09VLVO2NT MZU1+C)2TFY_RWO=MIO&-2V;_R($5PS&6L.3G*%?DEX-Q1\^!$%$]:X MT#"Z:E"K5B@IOK#V3]1Q18^5\[`_5%O=X1=IJMO],DU1)6;=`1;]'9>[4UA* M35G(N'#74_3!TVONNEIZE\Y5F<-]CC?Z8%4X)[]#VL/M2HZ_"ZNFYQK4)' MG^5AGZ*NK8YV9SKI#C]?'U_J81]($3R)()+7%D7L_V`5]=+TBQDDFPXD&28^ MVCSIS.6C[_DW5WBTLG:(27XW9Q9+J6@#%^B3#J5+!P<0V$2]V?.UUG4':/GR M:'B&I/UV/%PI.`#:!DRPT$\?IL5\=@]Q;UPD7)@3^@B!^QRJ8ML=#`6,4F)+ MV"=6)J4\E9I/;;,CN)YS6Q-W,1]WL5PM-!T`&J9M5<,=K]A3&H<4>=ID093ITW/*,DTZ( M6],BD],0<1:G5$DE\R-?G\8BI>)C(K$:A-YN@W_=.72%>]S-@3QM>>^I3,1P MD@=]RS[Z(3J?!VB69W;21=V[.!OY/L[+U.ZLOE.3+.!>^?ILJ;1QGBNZ MTMOUQY+VV,URZ%3@CL`53Y7@>!=/A)<0RE62=NCJ(Y784K'@B@Y7,YY:.BR* MJ,#6L)67.[IULL,ZF(E!^8"03&]>'Q MD_WVSJOG7W*UJ:B(19M-QWQDYB/#IRRSQ9,7/$X9)B&86(SS4CSAV*5]TO`Y MFBU,YXDW#/?'P_V>+ZXAM'3@MT(;$"4NL"Z9\X7,Y&,@%Z;77A/+4>U=#3]2 MA$G"O!:E?`VNEY^U40VP462:+`WQAEO#7[.(>`=:BJ>^*H@MI;M$V,0C(6_3/!]PBO51AXRCH!'>/*K8?S3`8WU:I/EB*153&4Q7LYD] M:*^P6!NH8&?5NC M0/"NK!BV3%L3VG1S5HS,MZS9A,-#&.X3Y+P,F54@LP*RD1=*:9*4D:$\7%[Y M,J%K>&982H46JS@52WOZ\&B<\V,^V[!'=TD6N*9:?6#?_N/'>_LD'YU52551"E+E(0PIJY!KM"@]CBQ!@SB! M"&\(^\=\(R*)?4TZ,%\07F<^P_V%:V[-&:FY>S1TVF1O#E@C,H1;4!RS^404 MIS')LUX"PGMEI0[<'6#@HAN09A0LSG>M6U%&CK9]YCROW<9;!X/-$WMGI*XK M_):Z6H&_C$3.`6WOO,VF`3/,=)WK$G3NQ:(@[*XVVA,X*\>-K7A&>/Q-M(0&-6BD]DF,6PXZ)G8R;!V::#'Q/[#:.L^7`P?@)#OP^L$_#> MUMYP\.6XT>C:_M/O_&+)(IAFJ2]9VL(YL+@#9UR+MIS-SB>@5U.(3!.+S?/4 M/D>QJQG46A&;;.G<=YVY)=494J`S&VF:)>MOF^:-:RZ-4#&H^D%'VS@*1ULZ MA]LP<\%:N6HR6Q=R&QAOVGD\_FJ.7VZ.\WISG._"'-G_.7/D7\WQ?]<<2T=6 M]DVN&$_I,UIB<&]).:#;JXXA4#*V\QON3X"^1/2EN8W??V$VPZV]'Z$\^C3* M7]>)K^O$UW5B^SI1FP#_/UTHJF:%,='9U%(*+%WQ:$-7H1@FXGC/D4>P8/H2 M'J)Q45=1,<=T#^%Z270"G^%C=P6J"=4:C-?)G1<0JUG/!+M:.//`PUV[BP( MA^;F0'E,$VS*UDMV%N)3O[]E/,IM94][9T/KZ=K'M;(=IL01], MOU2&3_ZRI?/1IW-5G-6)F:TW63O\D)_1X4XVVAP,>KV(CN]HYR_=UI]V_M)M M_9V[97D7?;-]I4,_(I@=4'W!$#6?[LB/-O6V0(7'2*E]R=05OFY(9V^2O[]D M0\XA[#_&2EA^=%=^E_+-S^]@SI9+GMB2E*TPEUYLTEA-XPKP;IN[DFA9&=NK MF36%-Q\?\YO!!JQ\/]X7V?*JVYM??_RQF=\3=I<%3%\';.FP3+!*P1'``>ZP M/.[?RJ#&!MQ2'F=+#'=*Y"^%Y"\98Z\-;/XUXYV^^/WY;]5^K5IOJUJ34/^H MHG7U3;^O->L_IF:=AU7[=S?J@VFTGM2WSV]IM_.HZW!>]5SJ_K%(7`9D7Z"D M/X62\N62CK:N./U9A%Y=:5SNL#8N[[XX3L]$JU(BOWV=K*L-X^V+!Y^Q.T+$ MXEK0]D3W0Z5J[OYF@Z83V+H,H9K2YWCT)QZ$I'=Z;&RS5,;%7VQ1'#LSJW:\ M/KWF<>S6VYJ!<*2'F)N9GR8\?4J[BS:VTU[C2;/H]:RLB97(OBM/H]?3=OD- M2;HBXSL6L>6/Z-S@S/(%72@W=H4+=T@_K',Z4__`U!+`P04````"`#P"K8>N8@L`S<)@58ZA!)[7IZ9>3P>I]F$BTAJH/]O M,VU`P-\SZ=]`).A#A;0W2&*CBN\((5=&&)E.X5J:1&3;6X0AKF4LS:)G-T-E ML`ZWF"\<6+%.9GY$>!:Y]PI@;&9A"(G(;S``%0?@JP!A+C3,-`86B<+Z*LE$ MCA#(,,2^:$ISFBCPI38MX3,L,518C:+%P:$28CM6\ M`?!1DGJA9G60!E0:+V!J,V@=V@QDJB4%$?!V-+9H<[)7DJF!R^&5K[3'2Y%.8ZS" M/]M;E1S-+$\]RV.-]9Y5UCJU3X-JL[-_4*WVR>S'$D/+])<8K/\IQO;6Z/4? M)V\N^.#[O+U5,H!$E)CYU*^#'XD<:C7:W#I\5H57,JC39XQIW<6&(VB1)!<) M:K>6;7)69'P$;0[H@'0D,]X5D6O^+*]#+1;:V`PJIR=7@U0:;WAY=F;SY%`$ MH3),/4[B2_NO.HRNSM^.AF<3^)>6KP?#X_-)84P9D74H8Z35U$0>^UL=1R:5 MY_*H@CMQS[K4#IV[RL&3;+&WYTHG;D7@N>)W&>^+;->(4E3+&Y5DE,LXRZ5![HG',;J=-0C.8AXMP/!,2WB@ M72,$*L5&H\%)_&`R8Z5Q51O!IR;T=L9&Y*8'D>0A>(.+WM=TAPTH[A2-'WG6 MNN!X[.=(I#H]#'%NAQ?I:4-EUK5+A`Z,MG]+CQ+5; M]X@C[V>ORD8I[@RW8G^I_+Q2=#NM:LWV[TH]6?-K/50'GVWLU7ZRL1=&D*3L M/B=,\8Z+\,I>7/:$EM]1A86\NI9DEN,M>13M6BEI(%UIXW8.NU^>%ILMPRTY M(_8]LK7P1&N#2V@?M%:EL9#K:+=60A+/(TDT>GRW++LO7\$ZMFS_P_UY^5@A53,S=;2 M@;_M)5N[AK;M8*/G2@3&9]439UR*URYB6:_+I[R$>P56\+F_$D]6XLF]E*B" M$^/1VIW/"MVI7M:K]X$D?%;R3:U-P\7`TF@$HEP42C\993 MNG4G6O17YQ?EX#FMW&VDP!>HC<<7NGB!G&*]M`WJ:TW+HGVB"HL?;AJ.HYD) MU-S-PN4PY=D=H\$`G@;%R_;D:[I3OG+E*_K;?U!+`P04````"`!$"[8>;X$8 M8VH3``"K10``"@```$9%34%)3BY#4%#M/&MSVSB2GY6J^0/WJ6>VRD-)M"W) ML>.5$T_E84]\DSBYV)G$EW-E(1*R>*8(+4!9XM[F?ONANP&2LF5E9L[>O;J* M:T:B@.Y&`^AN]`/,9NL._KY[`"TX/'C]].@8'^^*(L#I*#%@_Q-I"OE(VC'6 MWS[_")&*)I',LL%WFB,L2-DF$2 M;=S1?#>_>_#=@S\E691.[=0>C^V$5;0QVE]HE./%EA^&4AC;]D.CL;D)3\T8 MAM,L,B5S./5\E)B-11Q"0(R37&2QT#'.>"1%+/4"Y#1+KJ0V!&^AGRL[^20S M\.;9OQX\/X58#I,LP=780.8MQ.E(&LGMTL`,UW0DKB2R,9`PM@/`A_G*:I!),\C?Y8PC15&N9Y6D!*DMA:F2,M&*92SVV MN->)O/1$1FH&XVDTPNT6&2@[C9'(+@A965H@XPO+H>TUD982)^`I_7KT[O0# M`'294IR,QS(S=I($?I7H?"I2AX9REEMVS37\EXT_7V?MY-\;;J(MQRMM@)TF MDE46#@DAP4&1+Q`PC+VMK M8!\?PXP?BZJUL*VC^D2.W[_^?'+Z]!UT.QV6Y=?BTLX/M5Q?T$,L3:+%()4L MG7>AI&SF<)]^%3I!VJ9_=_J/J]J:ITI=3B1:J'$\)>;BUP4-I%5KP`O;6)SD(KK\U-O> M:6WQL-2`ZA5C-V@9Y2*[2.V@N0*I!3%]#?^M,CS.AY'4M%0HVZCGO%H6A)$` MWLE8B]G3-#U,Q04\@0X-^KPT6=.,#)8P2$43,)UC(BMFHL`9;F[2',=B0FM5 M+=B;#/$16V4@V#28PN1R7"*UR/#@=-WVP`\_5)U:Y2*7KM=VV@?`N:0,RCU;Q%\\M]:(&X/]*ICZ&:4B MD<+A-(MH12=:Y2HO)G=J5%@%I')-^!EX*HDL>D9]3F?'/6)J<)(>8=`PVOWOP7]\] M:!#DIQ+A')X`DFMZI+V;,.UN!35;UM^K^D?87_9`^PEL8B_IMI]L-0%1&H<'3T]>?WZAQ>R$5B]8JPSG M)V8ZZ9Z?A^"?[V9CL`L0@29.\N$-UH'UP#`2L&V:43.K"RWO`?2@8O`_XA#O-[4WHS$7' M_NWYKO83=$5:6[T.M*&[@QV;FWY7U-O*]`8('@*/ZLPT#ZW3N,)+RNXS\NAUC;IMP4\.2(02N%S7`Z1H= M"4<7=F)R8P//$3S:M12Y!/3+8#IA1\QPKW/;G"U``>$(+NAV>@_M;#&>44.R M$[0WQ6WPCW9VEX`CC]\''NGO?PM4)NDFY4<[NPN$BZ\3YJ7M M=6IT:=V$D>B2DC_+"]&W76,Y-C(/O!\<0B>$;F^7<-'Q0`?ZAE>>*^BN=R%2 MVA*;J"R6620W`%XK3W?T\TN&>\1P&GV')8#/WCW]Y0`!=YTN/M-2 M7#I%?(JJ@JJX&([CME6G7MU:.^7RH3BT7)C/WR]I4]V&5P1HRU>B6%:\ MM3/#M.)][CY6N>QSO)2+2VG@(8P'L(;IC(*<'WCT<`<.WYYX$Z,PW9!S+%;+ M0OUHP*1J1C'#$KGI;>_4Y`:]:W>RL-0L&R9)* M,;XVNA^;CJ/%\4L/\K;1R['1?-]=KW(];]I-&OF$EH0E,F!%CR$ M-O38AGKT3YUS[]B43=VRB<]?'!Y#"Q-TYMW>UL.=1[MAF7,@MXGP2B'08H`> M!!UT_04J01G0%_[!FY1[.J1/1M,\5K.,#NI#+:6!L1PK7=B1$XS#KV24*VWN MX;SU0P?+SEE>DQ.9_ZS%9!1TYENT`$/+H5^DJJ&XWE"I);=]50@):U$2*PES MO%AV7Q"[]^R>"X%BYN+STR8;L M8FYL;#1=UEY<2%A#9_5*ZMS@X9@K0!0UP_QM+G6&!TCR-TD;`56L1ZBQ?:8,1C).4J'O4#3X)+R^NCX$4E,=W8Q\0FCE\H#(F6*"[O=W6%KE" ME$95D,EY#FF2.3^8*%V?YCV8%_.++#@C*)4W[_Y@J<\N<&7`UC#1:"O\ST)-,5VA=(XYZNC2U+):V<<0LK.P,B34 MJH;#>8B?A6_A5/YVMW<>@D_+>P\-39&W$W[,:*J=/X,#Y!%U5#@AA;:$VL'!H9C%D<@;3R41J#GA\IH`VW9>3 M(RP]P* M-5W?_PCK96#B*ZDMV-G>WMJ!3:`ESLX\\)D#?EF9Z.O`:*UQ[7#-FKR*V<>R MXZSL0)K9V4V_&I'7+4H3]O>AY\LPVF!N7G+8(PP,ACBAC>.@UE" M9S5";U@I-C;@G41RF)57*VD]WW>C1WB_]>FV-M5E@!DC]> M86IKYHHW67D+89@JI8CBE@3UR5@Z6YN^-!O%D)9]"'[.4HFQI]NT53; MP4AW]C#10A^VQ7ZN[^.!4J5V?I8Y3)1AY59#SB*PVJ/4-E!_+&;-V24BE`J$ M->AM;Y]_ZIQO]MJ<-4!%^QIXMP(G67M_?'CT,2`XW%_UD8]N$JU:'VZ9.N,^ M%)C`(N^3?G,=U_Y\S.+:\L*Z7G8C$E5@`DN6L`J'=>:P7OK:.6,5/OW5**L# MMVMNB*.O=YMM2\Y^M1:X"('(E#6@KRPEIG@=BD7ZRD(B<)/DEZ46.8=!035_ MRLI1,FY)XK>>P<\^MK.S19[/0QH-QRUYP2FL8J=9\W1T.E(!,)"AQ.I8ZR2Y"7XP;H`LGM.:#::@TD?(#BP2!,5^YO;O3 MYF'@S<"H5.:8S7R%%SPL^<.S(S1'E.7WA;R9TIEW=S:\&X/0 MRH'?"FU!='*!'F#)%S)3CH%H7&#Q(\5XLHR6HM3+[AME!H:\K7(6 MD19YA!7UAJ^-Q#*$EI:Y][^PI58`Q"89)VBXN#;2J-UTP!ZT:4:6`P[0$W7( M.`I*[\U0<>=A!W/Q?$%D/%%:Z`(&T^&0L^,4-R)JLQ8UTF]*4SK#Y9S/(3IC M*]EGJMNT%MYLD6V@O$-[V\@\$6K)D2QM,T3R8>N76&9-)3A&0F)G3-&:;/6A=6PM8AWCDVVMK88D&O!\][VYR M1K98)+6(4I&J#V%)\89(>Q'AGS#^6R0!%[)LY.T+$@*'M88DP MDL49J;GB%\7U?4Z,DQ!9PG57FYUO.W,[C;VR@$A`6`RN=:!+2>DBO.Q@1\$P M:)W5BMPXE.U/3O/:;$,*[6Y5^LRJ]%(:=TGBF=,S1?E)F\..? M?OJ)T%"CRUN`@9GO[W=WFB$$IG!/SI+S!I?.'5L"&K-L\C6"VK#]JF=N)R'% M/,2//?Z%5M9^.!@_`5Z$QO(%WEK9&W7^.&[<\[U?^-N'"ZD2,5T`[9?M8W4% M(@WADS1)6PV'YWM@I@.(;9-([?.`G^/4779:*D5B;T7GCNLL)6F9(`6F8$O3 MK$E_VS;/77-MA`6!6CYH;Q5'46]%9W<59KFPO*Z&Q-:9W`;:FW9IC[^)XQ\7 MQ]%R<1S=A3B*_W/B*+^)XS]7'/%Z<7UJ3U/,AQ9TQ&!T2CZ@BWO[$&C,">'\ MNCM[0#]B^M%__8C;=E;U?H=S[;92_G1/?SHEOY\3JG^^5V*6R(!R*FP?V[63=%<-XO@*],_BC:[C[YQ6=#W\[5U](!F068\69M('ED-L/ M,G[#,YX_Z6QLQ#.JWV-0JUSH3Y&_B[*)?W/>EL4BP>$+Y!4O4?KHZ M$07UG*"BBA:_/^(27S=69VNOO'3,)F^JO31R_.861F$QDQBDI M3DW7;B,;S*9)#5A%=,5?9J7/1?`EB3=O'\O;&1:L?FO*)]G*K-OQ^U>OFN5= MC;$<1Y,BL'TA<.JP3G"1@B.``]QC7MW?*Z3&!MR25Q<3-'E;6F1?U'):T7;YI^RUG_8W+6I5GEU]*7&].8WLA: MTCZZI9WGL:S#:=5S939/DLQY0/S6`_U+`;F<3*@F=B7I?Y<77_ MR7%Z)EH+*?+;S\EEN6$LT'__.Z(C1*RNYJUV=+\L9,W=.Z*&2K?+/(1%E[[$ MHU=*\9))ZOU;IM*O_D$#+;&SX&WG%W;3U)VW2P;"D=;0-[-_37C\F**+-K93 MK+';K'H]*S-B)>87W&CTY;2=?T,KO;#&][S$S!_1N<$9\P7K4&]<[[(K7G*_ MY\LK-5=*_2Y?ZJ9;A,9VL_XNU/VY2(MFWO'06OH>UAUY2S>(?\US^I?_`5!+ M`P04````"`"J$[8>E@N?TP\3``!9*@``#````$5624Q55$E/+D1/0YU:77/; M1K)]#JOX!_:I_7`C*TO)IF0[CFHW+D66'5;B6&5IX]RJK=H=`D-R(F`&F1F0 MYOWUMT_W@)0<[ZUKTWZ`0*"G/T]_D_C$=?E<_?A\_^ M%EV]O:#9;#8>C4<7P6?K@,Z6+T':N,=D%3[^$;-/Q MYWV>G8+.";VT\WZY='[Y152.CY]_"SJG]&9+M5W;)G0M:Y^J;=78SR`S??QL M/#IA_;P*L65-LXI^/7]W_-F?Z9/I>'3*=-Z%K,IY8_,JU)\KV/3)MZ`SI:MH MZV@V_OC+/M.G)Z!S`CJ5F,S67T3GFN[1JW<+:FFZ,WINML_"PZWSX> MCYY`/S:%IO]B]YE^^QQTIO0FU)9^._[2S_3Y,]`Y43K3T]67TOGN*>B/ MJ;R_,8DVT>5L^85YZ#/Q86WP>97(+`,Y3S^$V!A?T\5?_TIPX_F6VFVRS8)R MH-KRPRE'DRWEE:6E]3::AI8N(6+&HXTPK%PKX\:UB&UFB[DXS_):=JV=X(J_ M!TLINZ:A*OA%G^`/T9[123T>K1.=UA.RN3J>4`IWA$A]UX5D:S"55F$C9&N; M7.1[)R_)=%T,IEKQF3>!NCZ/1RX7;4T(EWUURX\>D>6G*'6L%.6E87Y9/T+Y M.=5,L(*/I@GXRS$TB:4$X[5;+%S5-QE/]HD%8F6T6SI7#GWP]@.KQ7BH_X<^ MR[&UJU4]?,U/C4=W!:G#,5OV.K`&S"+;2(C7QF;H+^.EAYN58VY[/#\]73%% M7[G:^FR:9GO(JN'C(GC?A'@['C$=3183TA?!%Y\S9ZN4L*&UB8Y9!-Q!A6RF MUL)2,^&/3)/P/'/`4A?'^%1;EJ]U7@6?JS==75#7F`P>((FO363KU[W%,R_?7C]Y_7X"XE7H8[*' MXD_C45ZY5#QJIORV8:UTW^9L-F9"34B9V#3.\ZG>9IC2JUTG!#GF=FD\2\AJ M@[(?.GM&J3%K_''V_2&Q[B]"M`T?^4O8R$$MS4UU"V6PK#8V(;"675[1HF^: M\6AWU"J$V[[38PP?E`?#]K@X^UY#_4_I7:/\!K)!/-8.:\:R&'P@_NHDQ$49 M$N*4;'0VP=5,=LA"VE*H:FX<,WCZ@S,9K&?&!]P7>2 M6MX5PP\6!Z9,3U=DA)/QZ-7ET=7%;[3BOVL+#ZRI[X)7)VWA6`];5A<-MYCG MI.JF)S#;Y1`H+HU'9FGX>\_?#?$RH7D/H"AVQ9E;L+P8IAPJ MK[?W*Z]B93L(PSJP59_-O+&*Y.H-DWLO39C%/WKF*,&16GA6XSS;A:UI6D16 M`KJ&?KDJW#G@$1L_>G#M%K0-/0N[;-@J>*05G5YK,K$>;T[@P^MP:^%%:V?. MQJ.!!UJXQGH^Z?C7\W>%?]RBZQ]G5[@GGC&W@A55T\,_$/R4#-SPF.C-SCLL MJBR!'0.,WCO*";#PW`<(0,Q8B'`-ZH+S^8S^F_DO2BC(`,44+!E"Q+!5@4[C M$<2-O1>?>D`T4P6LS-H6I)K@QL%:/&?.VM\.4$5U\%;>0V@LQB/F:$++:.;E M7%K$T(I+D/*:0A\KJQCR,H3VQ:'$?M<+Z#-O?%(4YL3#E!4^Y2`K0X86O1<= MP%9[X=BDMFF(SP&YV0%?)\M7>-U0%;JM>JR2VD!94$?OZT9L6)P*B;V_-=K)7FN'#A501]HB0@^L@3RQ#J2VTW!2/RR]>O`!W M4/'.)]Z_.?_I4I[BX^#QK;FU<*2DS#IDSA]MM`=IB.K*ID0S9,`SYNKQ(;WA M5UC\37M[/#N=Y':N%LU([^]<+ZD'>1?9'%G?6:"A8I<@>[1@OYK>MS> MTM&*CBRN[0=+W\M%C,C5K`PX]MQI!MUV?-:$"5<&4.11F(12)66[CQN0@=^, M1[M;[:WFB,YUEIAZB)*K]Z_$.!&]:^@.%0.;41FG.KJU/?LG)/_G\!9"B+G@ MH]4BT*)Z1+U7]H1F!RV9132N5JPUT=Y!UV0S]=UX9*HJQ%J*D8!LJK51B%M: M.1.K%1(.S,),V+63TOZ?7:A.A8D_>E?=,BD\2%]3M%UC*CO@\,)]*'@?M#R" MD'!A`8$D4*B!>L`&?'DY*5YNTBVU`!24/J'KD(B2.APA+_+]E0'Y91]M/1X- M.G`^1U>QZ5"JP`N%=6+N6-[@)2U_-3VD<[_5%(3D&Y4KEU9%]89V+=5DJ,05 M95CQAGFVZ$1=0)4S9^Y7BI*[;"-%:A<=7&.OS$5HFK#!*UO695$D1)R(&NP' M`=$);:"Y8ON/5;[[B\5XC^,,"]+TU>U$U;Q!&HTVH7IU'I`#QN`Q]4>91@M' M%GP\JHR(YB%C@8L_=>\"%@486;AE-&TB%+@E$86-%XAM;)O4WW=F54JLY5TV M7]FFH[;G\Y&=F/`K%U-&G9W8G'LTDHAO`R+.^81BV-:LL/>K[0NB33T0I&1M MRZ8;CUCRC`P$(ZQ%[4G+6(?LCWHDE40L%6)KC6`Q#FR*+'1KM_-@8OV`&3N/ MR]6#!T37M@J^G@P)5IBK>],P<][)*0]_!@ZU]L$AO8[6L##,G^ES:,U2JS:M MC:N<1#LLDV!?"R0,&[NV4<@W2H;._C:AM]>/3NB6+9I`;)`C=*PFU'Y\=D#- MAW3\\+R]$]A#N1L\`E"[#(<^_)!,C6KUT?7&=+2K*D1WBP#`=T/7([JH0J,F M$"F97K-%X/YB/["``57`.E2:4L("3&JK`3^78/65\6584@!A;ND^,M?T*,>_ MQ^1H%Q(`T;1RW?':`(O?BX,-3R%7IH_8+'[)7%E?2Y<#GRV);.-RM6+EW_<5 MT9'$'0@PM[6$9EU\-6E)N5F%O:40:QNS32\41K+4HV]S5%NY$&]M7EOV;I)[L=/'``JUMK M.TVG-]#2>-2ZY2IK(XB6H!2VFWKW\-WSV881JI1:>/=FNZ6T3=FVX]'9WZ0X M@N2HEA;N@^C"L7HZ+80;IMXR11\V#Q0Z9&#W4@=VMO69+C"PPW???/,-O==2 M]4R=NVMZ23KJ,NC[?'9'\M7">)-=E30E^H``-C4Q#8&B4CU(3IE)NO0$%FWM M\J,=>C\":LO`<"*J<"AQ_)9O>9`.O;294N9[&A*=A6&Q.B/ M#^D:K3CU'?HAM+5;1&YKMO!L^0HU6X^N[-7-%26VOTX9.AM7IDOZT'AD*)IM MCJ:"R9=!&U)-3C,`]]/'%*7T2C0/'Q!LR,PVW>;0323]L2SSZ*QTBM)>:9:" M>N%8/P>#[DTS``L/S4P0#@L\R-Q(.PYWB/:/@Z%E2HCODT.ZR+$Y.F_RT??T M\(:_N944?F/2[0\F'I9"`0A4K2)*9/"I441'ZK[:H-ZYKQEGUT%$6_>55CMH M!J"`5K$;0R_*+C/?VL1)!N<2&D=([E12KI"#/';8*BS:S$-2H!!`&JP])[H>J#E,\ACUC4>\2E2$JOO/SND=[U7/)LM@$Q5-,QH M4J!:E.Y&AP5:TY66L,2X-$^Q]Q+5.S`O7>Z=5*/Y[S\E'%%`,J[6`GH0'\EB MAZHH,V\5&)SGOQN;99S76LE*\Y!7DJ&E.M@/2)-I[7ZF]7_29DWO'47F3O=. M*?J-I:<"3!4_$E6>5[G769'F.,U&RWMC`T%6/?D3GHQO4+,,9:`VEZSL*`34[H3`T57:5E2)CF"NR]$.=PH]<__KZ'#%V9\@E MR@5<6`^_KR$U0!SE%;J7SLIX:B>0CXH@YR4F:5G M4G>>-RE,6-F]I;9OLLLF*3=)#`'\E\;[H&:S;>\,AS0I("J_>ZKS-#X=MI*Q MO6M,W'7ZIG%YJ[7$RFXQ>D'\J0-CW&JS89UAZ(&`2U8*L*V,09O%KN2K^&C) M5I/!WU&YCD?2P<#==@GJWJ;KK6RZ)%V^MTTS*0-JS>`ZGG&-??'Q?*A$F1@5 M66I#IR2&P">2#L?D4!^M-)#N78;3. M4$VC77(9$I7V7QJ03ZW91(YS?V=D]$=ODXY3]G,+E\X&O(P@H`67K@'2B]W4 MP4`22=*M4I=JJU03.PACJZNML4LHC,G>[N@E%G>[&9].8:$N)M)B)CV/?1;! M*L3$%;8*4.3=G811LL,,$EBX;$1%L4C.;[X;YH'39]\``]NANS%MZ'6ZW]H6 MW>75Y3NZOGHWN[F$TUX8:<>088?1].]AGLJ@ETS,6.P(R`?T84B)7MMUTSB3 MI(9`*,N(3=P.9E\"OJ#KHE`9*`Q3D*'?R1K`V.N4?(/J#?X:.A5+:E6TT1-I M*6#V1=^@QD'G;9A\PR;4(E2[ZB;DM!=6PM*>"=WR+@):MTBR1&$AL;B1=^6( MYP/+Q8SWUJ;J6C(/D<%[;4N=H94%.BH55^VG,-FY#[;1(>$=LXY'(+(;C<.=_Z`]`!JC`Q$O MG3XZ+=X.9"RQALGW7O/T\`H53?F.=9T4Z/4]]S]6X4'W6"N#@1+_'8U/:!9] MY6PZA/;?P,FE+\=^T4CQC3DP[-:R-IRWGS+<1!PPU&:;AL?2>"3R5ORGE5)6 M=@755B?+]7O;#0;]]/[ZWK)E@#_Q$.=W/[C0I0/2 MBA1CC>X\"Z:@I5A:JDTV$ZQ!X18#C?E6MYY'K9PF1=H^S!%=C2;%5P;C#84) MF8X`?GRR<]JCSU[H5^=3O`$J4L45WR(T20LKC8>56%E"RSH;[8&@3Z]WT,.Y( M8E>KTZXY"CTC@N`55*31+9W7(D)*@-\.Q-R%L*R[97;:ZJH4ZUI=VPY[;ZP) M4NI;01)35DO"U-T-N'9MNIKH4VF[=L,<69PM^BB[`UW:R*N`':F?HAIJO]7$ M;Q0T0P%7V;#H8,!HNB?AOL$L85R[5/48,]S1#X;'=W]&(XA$5IO7H\3;,A6R-`$8F8@084>+[ MY0-)FS]8>&.:?'I^7<8"0V\-,!R/!`TUA>PR%.".E>[8D!@_-=F6S6H&LNX< M(A4/`>IB,<^FE+$<.K4D::?4*/<]Z.;'\QMBXP3QMILH$ROI^-9WE2RX_OIF M=BZQG>B[R?3Q9#JEAR_#KK!;80SG^W9NV?)1IE[X*4`H\_WS;**CY_,R5HY'58DFK0.^ M)K@@A;4B+*JO%5LO)_FYBO6#R^CODL1=?C#`CRMD8_@-*J_6U759`$S@QAC: ML2U8!O0))<5(?^KK_8`"'2=^BE,-OPR@\YO9;L!05IJ8X1^)U9$D4"LC5-@, MOF\,I7)L._`[LVTF#25! M:HJASZ@AM(LM.V4^Y7=;(=\&9`F,!(KA;:N#6C66(%Y9"M>![B':/JFM],%35M229D$L+P2(!`1B2",8"M%M2$QPE0Q41" M#"AQ&)-),B69I#,3"&HDF#XR3%1H$?$!$ATLM;2@8HD*RDN@RFVC8LMG:1MQ MM*%);=K&SXC1W/\Z,Y.9\%#QWG[WYH/?[/?9>^VUUU[[G-TPFE*4Z4N56^?? M5+AH?M[2_+S9TY:6V:ML#F=F24W-S4T&:G@FKV#JU"Q3DYX:'IM6EE?S15,, M-7PQ1\BS\_./-*53PQF7ZX4QYS=3ZW2LL+O<]LR*LTVC4:KJ[FUCAEW@89D5 MK4UIR'^F\H4Q(RZ0;W-7959,:TI%$P+5ZVR5596EV16D#J$.7&_OL`0(I+8W22CE''C>"+- M[+PYBF;.S$4SY5D%!9KI3G(Q4BI'%=BYLY0=\P*D& MI,;*XHF-.M)8\<21G#@"[<=IQ#T;DT@W1YE5L&1!C,4"SLJ[J2#YD5A*.ZHE MBC<*J7"C22VQ:$F^WF(!E8+MG%\EB!*&"&GGH[&DZY?ZY7Y-O_:F1R4\N64W MZ;DKNJ$J$^W.VBI](J:SVFE(A,1K2SSZQ))*F]MM-"5:K6Y[>97=Z=&;3"45 M-I=L(MEDDDV)LDF`.I/L<'H23$-KG6Y'N=->FH:H;))ETU#9E"Z;+I=-67)N MDL8UE.3<9,,RF8QX9D*Y^,%X@R/>:G4X2^UU:E3#T5)[I<<64RZ6#[-:RYSQ M262L\;A*'65E5L^(YA=I2%%V765U]?+:&HNSQNG@^*KH>$)1]G+[*H_MSDJ[ MQ7E[L8T2B[(]+IO3/3AIAX['8G5U.3YB!I58''5K*<2SDH*3HIO]IM M<:II"^VE+MO*F965N96V+%E#^E8 MV*8D4O]&AH8Q$`\-(S$4'Q4>QM!P0F08X:24R##"2:F1/IM#2<9!PQA('320 M1IU269)="69):EKO%F2NZ:9)4U7KEG2=BTQ2[JN2K.D[[K/ M+!FZ-IFEF*Y?F*7837N22!(Q1=F961;GQ(P5:E-_AA`$!VXM*O1^L*;+A*!7 MZ?86]GB+>[T+^GQ*CX\.M$N^PFYQT*?T>J5S4OJ\LS3G))F\LPQ(:B39VU5L MO>.@AN[/H8);0D\PJD_H]1;V'55Z^,F=FD:E1^8V"OMF2/53$4);LM+K6VR( MA/,UD7!\4`@Z"OP2`][9/)$29F$6J^$X`_=Q#&FR4K/&9HW.&C.SM%2=*UVBR62L`/N, M*XV)IEYCJ=WMJ2XKBT\T]7"+)E0S.J:@=E]T[=YP[3;4R(FJG:;67HEQ=\4E2R*O.9;T08-JI>:65A(\ M,A^)8QVJ6/=CK[`70N^( M;J+@EH6#&NAKK.\CC_ZHTLNE6@GZHY9_*A@U1D<;KU=[4ZL/!4*5'MV<27ZM M68H+S(.J^@O,DM'?:);B`TW0A3=ACS0ADEM8\17M?%R`V)3WFJE<,'S&^42]4/6*KT[L9`# MYF2,*Q7PCS-+0P)9&&'@-DY;QFEV3O/PT+U8YOX'S%+"2P\=PO.^H\IP!@T' MKZ,,\'K\$MU`>6`V%8(S:1FHD!O,I;7@7'H)G$=[P?GT&IA';6`!O0\NHK^Q M*:!_@D5D@#CO(!-X)XT#2^ART$Z98!E=#Y;33>!R6@I6DD>PMF\!G;05K*96 ML(9.@RX*@![Z&*RE>(GHQ>:QE%J4/=?NM+NP.I72U]*8ZU-"Y?$6*Z``_N]B2OV885.@@?6_F7/7PUX' M-C):`&J>3Z:@.9OO='A@/%QN*\5%4JR4$(P4V#US7;::"BMIR[`'1=(K:CUS MJEE4AYQ76ZZZ`@*BX<];&!0D;5_&Q;_NLCJY[&VRN$2 MD;(7"AU5^L("[^M7^M;`8K#`AR+*RZ=AH&#GGR_RO,,L5&QXL?Y$LY08,&,E M!%)Y38QC$S'!+"7Y83N&!A9P=*%92@X4(=>_E$,VEG$9A]:R>!]$R`_)#CNK MKJ(5-!*RJ*,4^D&<#4M`'],=X!-M`+TT@:6(VT$ MFVD;>#_M`A\@EN\Z>A-<3Q^"#U,W^!A]`3X.)Y1H,R6!6R@5?((F@%OI!IFE ME@<^2;?(K&:W@C\G^&?T"W*"OZ(Z<"?=)[-Q;0;/MKQ(NDJ(T1Q3 MXE`OI:3:6>8H3[-PMZLI4AZ>.$JS-I5"F_3\",>4\1;N84:PF#Y23-55U14R MIK^-$M]&SC`I$A[.JEB!R)HN=;<8.J`PP47.&W)0$=2-*ZQZ(X(;3ROVPY!^ M*EV-]5U4"V^ARZMT="Y1?[O#[@74KJ5/8&F_8I';=O-I'?R,H&W\O@GX'5>L?Z M$W"L1A1EA_T$V##8+_QC2Q;TLY+ANE8/SLQ8L8QSX,"&ID[-L2&]C=,3U726 M83`]8P5/7JAX>`941XXGB1\P2.1J#L\+&UGDS*ZNJG%4V@MJ7`Z//=0B_K,. MD2E8UWVC?15R;!F.-%[>OVL>?N%N4_KN*KJZ*+MZL64Z?,GI7#GHN@X\NL9I MR9OU767V(HL%P:F`.V,%3#K76G+)M7I949(U499AD$+PMMZD]$W9OQ9X:^TZ MEAXB]P5UHY>]UJAZ80HOA`ZF:]%+0:QFP_ZA,5Q+M1\$VCN1H MKN2%[54"01>FGW6N+80]9^48>^WY-R)Y.4MH.](8\#J\42@H@R7M0 MC7CA)D?L>DO42(*]#'>.?16ENS/&![7/&8%@8WTW)?P@77`6DDR7]:,46V=5 MFC[)EW3@[-A)!]_LS?$JIRY8!,>`A9I0(=OF:['?\^CB>0]+YB&.X]`5C*O9 M(F/_&QF8R47F M58%_)0_818W@WVD=^!%M`?]!.\%NXBGX)[T-_HLZP'_3YV`/:6&K/J%X\%.: M")ZE&\'FYA2ZN$%8RW-:B6(09CL+DR9I688'>DVJHD&ZFJB4`&9OAG+JWOA6 MMD63E%,SE+;54B=KV@RE':'XUC0UHWV&$EBM/=-`Y\UB@SI%.9J<_`MF&&:B MK7F._=R^K[CM1G'HO)70?62SA0)Q/&&C><*^QQ/6&)HU?6`K:_8VLS3JAN;D M\&EL5F78&%EI.I^\QL)0C9,F6MCHK*?(KI*>E1K!^-#5T2L(FUIWB ML5?5(-"E;G#J1N6NKG65V-,L/+7?BFK2$FY2M6H&%-7A]&Y,YRD:@U%NER+A MW=(5%E:$5$D]A>M-O*I(#I[^HJS4?7S&&*%C048$N"GH*';[%B8[E``+4,84 MJ@>.T$'LS.M?]/>_G!->C_>O2\M211L;%FU?V=&!$]:AL'FJO(!Y.JIT!7^Z M@[-S=F`#;&^L;Z?:.)_2[E7\9W+UH15^$D;+NGDL\3*,":3SNL,*-*K.IQ_K M+D7U-JN:Q_%+F\*;K27\3F6B(\,1BKL=SG`<[Z?$:SI^%I9_WR'AW9 MX5-V>)5=/F7[)R>]RFZ?%P":ZY-?R@W0C[E,=E9:OZH!-8<8W[94L?/[.P[9-WO6TAR^8]&!EP MPLXV[]L^%"X\<<'<@QF'U+<:/:'<`^TF<<*Q8 M!Z:)A\'Q8@N8+GX!6L2SX`2Q%[Q<'`0GBF-@AG@'O$*)#G"RZ`:O%+,@ MU*O$!G"*>`*<*OX)3A.SL3=?+5S@MT0=>*VX%YPN'@8;6EX@,=:@KH"(S,0A MWFAQ\!HDL[V02+3,E./LP1WO5XX/DM8,Y7C"`]E:;K+5J^`%R%ZOH?3>HSWC9S\"&W'M-:@OU/H#O9H2%=Y_D?2WHL)KH\(_ M"C[D0+O6>S"&%_)=,>&^"0BE72[L\$H\PJ@Z5T2%#T:%1PU^WG:AM&+5"V7O M?W:LQ:K*SQ!/0=S7B9W@]6(?>(,X!&:+HV".:`=GBK^"L\0HC%$1:6"NN!R< M*Z:!\T0V.%_<""X01>#-H@3,$]5@OE@+WB(>`!>*1\$"\32X2#P'%HI7P")Q M&%PL7@>7B,_!I4*.Q5%%Q()W"#-H%>/!92(3+!730;O(!9]BX4^,Y3WB:T[= MTU%3=PDS=OI_=<;FLZ+_'MT.3MU'X:G[SC=4T\YY4;$#%ZEANDB9:&6,+G.N MPC_))^-WL:6S`P('H#NCI-;%SH/ZUA8O73N,X1?P\8E)_?W]JR>K<11I-^*E M[BH$3G&@#A[(R:`C<@*."'X"1N<2_+09G8OYE'V%QU&RW(U']&:LJJY%2D]& MF+*K!"?!]T MB'KP>\(++A!6W.)#T"/^#M:*3\$50AN')XI$L$Z, M!N\68\%[Q"2P7EP#WBMF@ZM%'M@@;@=_(,K!'PHW^".Q&ORQ>!1L$EM`KW@& M7"M^#?K$0;!9_!9\0)P`M["_=%^J@+_WYD<#??Z*B.?*2[5SOXG%VOP M@'9L<*\CZ^(956,>%.]"W.M$/+K_4S$4W"!&@0^)">!&,15\6-P`/B:^"SXN M;@4WBSO!+:(>?$*L`;>*^\$6\0CXI-@&/B6>!;>)/>#38A^X0QP%?RG>!G\E M_@+N%)W@+O$)^*R0X0,_)Q+`YT4*N%M<#KX@IH&_%MG@'I$'MHK;P1=%.?@C M-C2G5-E?;)E_'7/QR47F*CTJ7!0,8WK$P;7*L28I*B_N(HKHC0K/':B_IV4R MZ>['D>9!.;*"GT>89X%U[F=1X>=E)7Z,<=>55*SRDJK MX!GI?\5?H),HWNVXRV[UR+E&3=IJG9RKTX[KEXP`C8QQ)6E'CC0:C3I7DC1R M)#/%J'4EB12-*XFTKA21HG49A2XNB1HF!E^LR+F7&9892/T4;DN=4..RKS#8 M1DQPVNL\!EMR"G\1B[&9@J\-=3:CL72)SF8PEB[6VC3&)5H;&1?')LF7#[0E MY\;J74ER1L85Z)`P\KMEW?.R:LFP!_/!^54Y$GX#878%I\-!^T-4^'TYT\). MZ29]Y/QU959JZ``6_D`0/!3.KBZU\Q3;EJP4\&+?@)8VF%:L%+5V;RGMP4SU]P5#TX<]UG_?T^ M9;^75]YA+UN97>HJW(U5>&;;6$`\#1X4.\##XEGP-;$/?%T< M!M\0OP./BW?`_Q)_`G\G/@3;1`_XIN@#WQ+2$**3P@B^)\:!I\5$\'UQ%?B! M^#;XH9@-_E7,!\^(1>#?Q&U@IU@&=HDJ\._B+O`CT0#^0S2![[(1YNH7/^2N ME*,.N?\_3J6;^*BFXSG)XO/:]3BJE?$AY_TA_+WOZYU8O\;1E+5/_=K>SA\= MV[S2N4DGSD_:?G[2#B1=]"1ZB`\YN#60JL[$3Q*^\6EW___@_'SAL^#ABY\% M!S+^S3,QBL_+-S-P&R+U8QY(-FP+5Y*5$^I9<8IZ,(RL]=`1CQL\UJ\<"Q[I MZK,NR=&0.J7.(=%;=^=SOL+6`V=-`Q,`T^%%K/6R_GY^B63B8:.V08V+@]'E M_L*]YEL97M.Y\W<,7YL']S/S$OLYN)=8&:&'^@J/3=)+(1_J=:H6[R+%?`O,1EJ]&^1#?:(A>#' MP@Y^(NK`7O$Z^*E(Q5C/BCSP,U$(]HG;P<^%'_Q"/`/VBUV@D)X#9>D(J)4^ M`G624.]_S00-TEPP1EK`-[:D/-`H.C+.?NPB_'=Z`2Q[?CMR[R?2Z.7W16V!WE%?S1KL>XTE'JJ3"F MLPPF0S]_KXF$3VLF6]C:_D:.;)69YVV5X6_IH[C?0[##?JT=82&CUN*DTQ8*;8/PW9_UOD73N53/U?>_@ZV;J1_ASKYP90A_4SKEV MUA1*/N?J&=][N,#U,V/H\]NY5]",\<'TWP?<#P%[P-^ MUF(F?3':U[M29#AT>M=(_I&2;VN91>(1J.#Y'L58>!1\4^>KG8K.T+:4[$]C M+V$B0K[U=?ADF5'TE1_AI@0_PO'K<1H3N:T1<<8&[FO8V(7[\AL=K+GTK8?P M]4JD2OLPJM'2:^`8Z0VPKF4"J2_@@W_YV<%?3\ZMA>I?*.[(:6T90NHL]X?^ M"O>L)*'Y9A\D^>\;?914>W!Z_0AHY;DW"Y,Q&KJM!5=`]P777FA)7X>CNIZ' MR-=`_]PRD0S!(;%>?=CVK776.U5M94V M3[4+YLEZ;=:UUY"_*8X:GJBR>2J0[5K'MX:?0"%$RM?BT9[_!E!+`P04```` M"`!*"[8>.MH'@E()``###@``"````$U!24XN3T)*A5=];%/7%3_O/7\\.R_) MLV-,0CXPQ01"J1=(6UC:-9\OC,\8G!#2!EX?]G/\5OO9LU_XV(:6DM+9)&A# M*M%*&[76C$8G;=+&-K)5U4B9EFK3M'9"*FJSB2)WHR-_1"O:LB[%._?9"0DM MG?_X^7?N.??<>\\Y]^,-5D*%T-@G[-NVL[MK6V>?M[.MH2\B*:K''XM5)UD8 M_%&G;].F>CYIAL&7&H*=L3M)"PS>::>8-J_W=\DJ&/P(O+^I2 M-04+Y[T6"4W2/*%/D^4%`WZQ`1G[0G)%065?NFHMY`G].;D:E?'X+VHJ/Y.2 M`54Y+,<3LB?T2;(:K2+?/%^S[#-60=2/)U>A?L;ZRYK[)_9:DD$;;O0!`$-; M9[M@:&_I:F%:?3Y#Q\Z6+E/[UKV=W5ZCV"7L[QIXT0)*C`$PT]31I!%3WTF= M'S6#L:USMZ_K7=2^U@L`+$-Y1UDPZ:V;?D":L14L#'6!&(MD@`_G6ZT,]<-1 M$QA$'+&"-+JPLMX%I&`11S%%TTRNL6 M7;U>L]N-*/@N$/T@ZDM+*/KE@I` MQ&S#>$95UH:5.N#7S#9_6$HD.-XFB@FY/R*KFIGG_2$ISO#`\#S#VQB>0C3Q MC*)JI7S9@)I0^E4YX$*1X1F&+V/XU0R_EN'KF0Z[(5X&3(>#?9H!#L> M>X!5BD5140/R45TT$#$@AS7)TD\]LTP4@VJQ';B8%@\HP:"HE9-I_P0[&^)V M]%7.V:$BJLI'%4W4BNQ@.4)F)VI6.Y0$8]&$J#$=)H,+JM%)C2@>EL2PDM`L MJ(T2;TBX@'Q8)\6*&M4[%B>4;\@Z*]64B*S[!>ALW2ZT=3$=:]BG62!Y8:6J MVEA,E`'?TW0L.N!6W?DFMQM>NV0'FK+T-'GJW>JZNL,D2_#7 MD1(P^'%=F$"Q[:M><*59,%>AX\%UPR-F,"04583+Z8M`$7/?GKW[>KI3'SX[ M3>*=$N:&A3GJ%FZGI@^( M!Y_L?>K*Z>;_XZ]<[^ZZU]^Z+_)7<+UE<8`AH`8Y*+&71YZ+=L2K@Z+%S5I91P;5BX M-G&=*4C3DT*6L%NF82&;$[)#Q[.NX^6ODP`.=V MGOADY;__.RS,I+S\O*)YB6+B!I]:4+T%]ZJ\!B23S:0006=O M`%#+]4U4#C;$"FA!7`%>Q$J0$*O@#*(+7D5GNRN;P0[7P!&?7`X,HG MC0:=!6#H^$TH?6X%CCU.S2?@Y&7MB31_MP#T/$[<,%>^.3%KIHPD@U^@)FD= MIQ?YJ8RCSKITFP38>U.FL_V M$L5!(OJ=M"U[E+`3Q&2$*$:)F$%Q;*09ZO2@[94#<>G(PA:/W3UTD6Y$2."N MM^NFOM"`%H@>*9P$QTD$+^(*$&0UWW$RNF2=J+XM(Y2E'J-=PZZW3![*_UH,%"WM# MN)X3KG\T=2>7FY>]XVU(]HRU0I8FH6!)*)PD,BXBUA)Q(Q';B*B'\22!4T3Q M72=MS[SBI,NR%_"4^&?Z$IB(6\Z>S](:O*W837E>XR:X2^!KJ^J7TF>=7UC13!-EC]=XJ"IYDL\4$8S7JH;W:JDSZ2=O)-< MD'\G?9IVXG5`[NDX1W%,1[4I;J>Y];2#22\'2F3NGKRL?H_A-;9_S`09'*#H MA3./XH5][Z[3%[MT9Y(H@)%,3B03A]FS;^#9U`)D;[:"#;$-*A#;835B!SR$ MN`W(>K>#@+@#`C2)XQ#B;CB#V`DO(>Z!\XA[@52H#WZ%V`U7$/?!.X@]\"YB M+WR`^"2&!.``?(QX$$B$15B&*$$EXB&H1?3#)D09'D:,0@=#LK$3\>NP!S$. M^Q`3$$(L2XN@!S]J'[K\^U66YGQ9Q)KR_S/-]VOW:5)<:W2%%,TEN9Z1CS5: MH2T:B85E#5^0:P*N8%R*R(E55@B>J<"T??:-1'[?3W\-3#\E;VH;?[L6WZL: M:^-G:OT#<6R8KDZ$E!B2FQQ^(N&#EL]RRL8B&W^=RSO'JIO*5QVR:UQ0Q,<" MFE]%I@20S*V7XOV'DUG](UT+A_"(GY'V_*H`:>0Q8T9\@ MRQ7!(@;#VD!"QBNVC#Q]\>G:L&6S*$<&PI(6C8-)%+?4;]E,_LF0\![YL'S% MCU]P#7&;SF,Z-R2+D)-/).P>_YZN02 M%H3@F=X&``"&,0``"0```$9%05--+D]"2NW:?U"4QQW'\7WN>>1`3CD5D2@" M5A,#)D9+8GZ45@4YI%0CWN4.I'I2A4BK8,Z[J+&-1XF1XS$6:T(UC0UH;&TU M:6W:"9II!KB45"U5=$QIZ31-`N:*HZUB-7&27M][D#'.6/)?9\H\?^R]N-OO ML[?/AWV6&6;]L2*FK+1DW9KIM$OU)B%6U:AB3N.S]18QS#UOKF.N)E]:=YE% M>;UF4I7"2(=G2G:\.4O]7=)H1IM"UGKGV!>YZG9/WB2F^) MMW2E>T.Z2*B;0%_\0%_E(D_IBLHU:\M7T[LF7;CJ$ND==>-*^V.^$D^I.U$1 M:ET"77']7?95/N_*RO45[I\*,;YN(AT)-ZYQ>$HJU@U<.$\1OZT;37]L?W]> M1;G7?8\0*S_[15FKR[WV%9[2T@KWB#1QO6X<7=8;]79OB6>=.RU-I-\TA5)O MKJ=D[2KW74*<_>PE"RH?+^V_9&.:^&.-)N;L578T=*O*:+'!>2]S$<*O\**B MAE%HQA@W$6WH\/XD.8B5_&V3@'LS`;<]"&\S$/\_%KN!`?Q@)B!]>A#Q_'#;@1-^&W\4G< MC%7X77P*M^!6K,%:U/$9W(YUN`-WXK-8CS_`W?@\OH![\$5LP+VX#_?CC_$` MLNS$03R$K^#/\3#^$G^%O\;7L`F/XNOX&WP#F[$%@_@FMN%;>`R/X^^Q'4_B M*3R-9_`LOHV=^"?LPK_@7_$=?!??PV[LP0\PA+UX'B_@1?PG7L(^O()7\1I^ MA-?Q8_P$PRA8J"9%^%4A7?C/3@#OX@9>!_.P@?P0?P29N)7<#;.Q2SDD??G8"[. MQZ]B/B[`A;@("]".#G2B"XMP"7X=EZ(;E^,W<`668AFNPG+\%J[&"JS$QQ31 MW'!`*)=5OX>W7C[VX7K<@$_@)OP./HGL`?XJK,:G\&GY+U]Z-.W3*.D?O'/AAG_PP[M`9JQXL+EH2;+<&]\D-*S`V6KZRZQ*F MO2`JHZMLVXDFN76USRS;UK6]^<@Q^5C?$;C-K'VD2GMDU**BMW+@HN8:52R M/E9>L'VBO#A21K>9N14&_[%GINAV.DS=S]-B'$IW,FT&;18MD_8$C=]W]U;: M8=IK#N6]AG.JZ8200R='E4UOE-/>WIEL/KIO!OV^ M6#5RQVVJT:L'.T+3 M,KDMN_OF^2^ZBH-.E7]8_U*/T4_Y>9?QI_T5E_-665NM- M;R:/BVT-F'6;-FB12Z,J5]-MT8.71)E5EEEU6_S@ M9?&R+%ZW)0Y>EBC+$G5;TN!E2;(LJ;HMM3])(STCO<]-[]">48)-P=2=SH/_ M`*W$H30VA%33RYH1K+$LC?2&=GH/-?2HIAV?W6_Y)=UJ-$(TE:*0WA-,[+)_S^^.-$(TE:*0WA--KEL]Y8J(1 MHK$$C?2&<'HGY7/^T00C1&,)&ND-X?3>D?^*^W.*$:*Q!(WTAG9ZIH8/5-,; MDXT0C25HI#>DT]O=D*N:&J<:(?Z/EB#''IVN`DX(7F[Z'4<(CRR2QR/WJWWS M?5>*!OJ.ZWW5;=&1@YJAX-OA<,;IU^71TFM]@830JY^^3Y7OG5IH+Q_<'@ZK M(F"+;@F-K&ZV!FR6ZC9KGB\X,-XC?%D?@R;K%1KC_KV#<76GID>U]%I;0E95 M>TZ>96S3S()?Q[7S<2^U6M6$C4E5K?)+0UFW&K_JNNSS)%7U1FJ2;U432)## M78@,Y]3ZQTM50I?/_I?Q4@?&H^8/MZH)R"DS[YMFK3LM-?%F>;MQ6^X,A\-+ M^^]9QAL^<^/VL[6.D*Y%SFRJS:K*`4X*RO3LX;OTD)X=Q4\CJH-6/?^*RVDO M4#/43=%ZOD6W:QE=C[X_IC8S63TUYE_#PUY3S>S:?^?F^2X4%2]S5('1 M+[6````H^@``#````$5624Q55$E/+D581>R]"UQ4Q]D_/G/.V0NP%XQXC>)J MD6A0"]$F&M"@LHM6HWC#.T8C1%-%"[MH4B]+-J8,!ZAMT]8V:=]836L2DYJ$ MM*NF9F$LX.4D@*G!2U*BONG!)88(043"_IZ9`2^IS?M[W\_O]_E?/I"/^YW+ M\SSSS#,SSSPSY^SFT24_PWV0$?Y[#H5"OY:0&:&^$D+)Z+_^VS42H><4A!;# MO^_!/UU&*`?^?2;=HCD9_'HG_*%Y<],36H.#_`GH<*VL/E^.]4+DG50K([?! M7RL'XWP5DJ]3V?(/(.KG3[I)E"F(/.>ZZB^!@(PE2^F\!>0_\QL+4/[G7D1. MZ2^%B&NS:B*NIXM=;<7IFW4C)JXMJFMSI6L;Z#42^UU('XVA0+\/ZU,PH:I) MGXKU@=B/4<-\/"=](0A,(Q7D(Y+1J0]E!';2E%"KGY1W!#Q.-:/3F[3,/=:; M-,8]QIOT7?=(;Q)R&[U;\,/N:-75>2@-Z7^3(:$_J``MIM[MH65NI<*T;"JI M(U?U"4K#>D3:](T*J=P1<"_S3D3NA4PHH-4[,=%M+C04F*:F!J\D9G2ZO\>Y M(^'SN^YP^'Q82*HP(2[L*04:`M42F&IANAL12NQ!&Y,EIP;W@EA&V;A\1<9B M.F_.W'0C*3OB127&5NA5;*$2?^E(/@J:I\461KD*^DT%&2VD"CA,&4L6@V'5 MZ&A)GZXLI7,/Q4OZ0X:)H9`[TA^.6.Y9P\1PY)$2`DNH?YA"_3$*G;N=FS(=JS, M=@Q;F0NEPQRK5N9"YR\VQ9+H#AQ;%-V*Y?.BI*1&O0BEG5@] M57-9_!?KG=2.D6>B:I-042"N*K$F)^(P1O[C4M'QAGMQ44`]6W-1_.>1#W>& M@+T%JV?ENMC=K;@D$%=7^GUM:-$_2BK?RT>%CX;>01T'',UO%'M"AT"7\EAU M$JA`)O658HN,_26W/+EY[_V!5P^@5V>7QFM#8W_?AF,+8J]C]8,D.>>[)=&C M4%SKV,]5Q>IP3(0NAJDITL3Q#WFP$Z;Y?D\[?'HN['>Y`/=ZVM4O8\F#`YGD M09+01CW/6CU;4D[&*!*!I@_&*^_5RG$?'$#-K_HF&27DZ>\O5O88I2*;6=H3 M#F"1]M@`(J6QG_N+E#WW0#I*TGLI^NMR&A?643P)H9+R@Y'(CW'SGQ:YX]4Z M_RM@G7*(V5*T;LD2]VK$?U+RAOA]W?'IILC9T49K^ ML;RH=*8V-,T/`NL6T1,GYLTAITBY'TW5AN;86JGD#FLMPV[%CXS7!]3J$PQL M` MVQBJ>.Z'H8>+>2(GM$Q/0*1\RHYSGOZD6E]A(!366(1^LH-Q&E#P*(C]Y<80 MK.43^O,&6*@9T.R3]Q2@6'1B@SN`+AO M4Q^,EG:TNA\`]S-&WQDBE<&A:GHGJ2(W]/$&4#"2G,`WO(],])B*G1A7!2/` MXZJ6'<<\9Q("W)DP[P!^TLC5N4W3V:]#VY&O@1X6EC)"RM.X[]45I,W$/)!P MK?F-NX2OKB#IF\D9_0,#B"D'W^*)T]^^0:CO$>P9RESL(.98^W''VLO_2ZQ/ M"G'SF4E;P^]1PV\1:=)/=2:#H_?O1'&NIXEKF_<1Y/Z,U!U*1/J38L)( MG?Y&)_D'KB1M(^M@(TAT;2LFK%%7QI6 MG*'+&5ON=-UJQM/ZY#`@4D'O$WH_@]"ZC_YUN]`Z`MRWQUB\'#=X0J2Z^`]> MU.5X8>`JR"G?=@5Y##`/[@U+"+6FFA1WA/<)TXWW,/+.-DD)QY@_=L&86,A9 M?3ABHC\G93M"[MY`]360*#`")NC/A#!21JI69(@9NA`RIUI3C9*GM^YN)Q65 MBL)ZXYUM=#0\@6ZV^4?S$:3XKH=[1A]!1B!/]L2`R$CUD0J#-60*I4IJJI28 M&NZQ00-U9M#"P$QRGZ`I$"0[-AD]YBXZ9M@#0.>I*ZB*O\25F:OVO5_9/4JI M-&;+R*%GM348VZ/GZ6J'^H_TPO+$:[F]O4FPS$(UFPSJ)X4IV%=A##9D)/[# M[0"9T5XP8'A$JN*60RNDH"DB`(F%TI`*DQ1\;^D0.CX%TX7I<^<<>4-^[Z1\ M<*+YK9"^.[1X2<8*^G!WU4D9/,W!1>:WD/Z"37,#3$&7FM%*FN*B^THU]5,-$L)U^D$,5@^X)^`ZM6]?:4\3)E7Z M]TUJ=!/>/5`B)F!7^[)"7[FDCT*D>7<3KKF(818A1!Z\@H-&8-ES!4,Q>7"4 MLN=^I3BKC:V8Y5WSW]=HAMF0T5;IZD#(F^1P&[Q)81[9%6QF\SW1FS3,D^@B M>>T$\L-8B(%8B+',8X65,(P'&LL\V%6<@G?4NL,*+:2BP#XU^"&I"%8WN%%P M7!.2'`()+.TS^] M1BC,I$I3&%K*/1"A\9<*RDF9?N(:F,&2?P/AW`>\D]JPG#/`>R/-H[QE"T9Z M;PS+4=[J'31Y;SARI+<,WO;>>=);O0M.Q8<*?YPL[PHJ!6WQETB%_@R()P]! M`R)BF3/7R"TL\2%,K'!UHL.+Y**S,(0O&KGW<'BW=2*8O57ZW]CLC8#$SC"@ M-0=K@1H'JRN,8Q067#4N-]UTAUK?G41=V[".8.G5V`_>+C04!B3-#G'F+1DDZ0XO!V3<\S>CB6;9.]1Q_AZ MMZV`QH<*ZN,OC:2D+F@%+ZG$!X*&&:[4X)%N1]W5$=\DB)$\HP^/XE%;0BA6 M-274PF"5!!+.Q3)_UZ=X$^8)A30'FTGSE*#>D`,=&-GFD2&BU2]W@H4JH(<9 MI+JFGDWQ:OUT)^2GDQM[HL'M)-26N#JYA`$J-(8_(M^++31-+5!GIYJ`!7,$Z,S.8V!G2_'VQGF->-$=T M(K^Q%:7-G<=E+#@]"NB6<21D(V\>%<'WR5\QERDA/XHD(U'`1 MY6];\N@2MPE@R:,>`_CGH)00(MNV@2^.?M.@IF>2?*,IXMG;=;W1_!^NI>JK@+]RVO0F7+6TF5_))*- M;AE7XTINR.>*,PI![FL6TJ:F;R'->B<8TCTDE)<=RML8RGLRE+MV%7( MS6+3>]MV^H[:5-?3^A$CK!B^/_&IZQ^&]'+CS<73M\(5G.L?BHK3+Q=G7"Z> MU:9_;%,S&F?,2*A576WX5*_JD@!,P^3N)9+F-R/]&>.B>7.-I)S-RQDL("TI M9Y\#SIF6=%$\!A1SYA):.HT5PZY5ON/<5K98#NOOADA5L)13/%< M25FL.ELFIZ9..)/+Z'J-/$-.E`2$6-C2]H5,T+H?C&TPLC,%FWA(OV[HGGAI M,.L26A-""<>"82`M$$OLI(PMB0TAF&:?,Y\C>>[9<-FX$C.\-"QIN'JR[V.7=W;'23. M(U0_;/5MA]/E$`B2)+>I,C7\.12\AT=,+`.=,``@"%G"]8AVDJK`"/6!(*FM M.-7"XB0H$60*1$$0L"@$V.`B0FQ`$(M!^)5BBG0_[%UM^J(UQ2BYQ_BV*,@] M0ETFJ?,5-<6L+[,R'P%'].#LQ!3)/4L?\"5S)1;T'D1%2<%)G'Z\=[41^$T. MSQ@(NW]-3H51=V]V5#B$T;4S(.;:N0'7]=>,X'X\%B;/!-S>F4:'FJ(0A;15 MIH!2PF>F+YP377(6@IZI!AGE3(KI/&1$<>5?W7OL.V5R.<1;F^+4349UNSFQ M$H*G35%Q(34JL3QO8%P[([DNMQ,_$-=H<#6W\PD+%-@05E!D#RQ.,5(G!).*DQ^0\A<`GOE9I"(5($YAM10;,6-^D^7`SUD>-?E)6 M3;C.H*!$8PL&-4VP*P6ZIW2Y;](VN!LS)`0:#B/?I!;*Y1/Q0: M64ZJ#9%H0G7.)Z0\$>+S7)/:-UMFYNO;`GZF!>?*ASKAT*)7AQ/*-I\_PQ[4 M%MKTIPGE>:\!=XVO09E0L^DE"'NY/G$J`&F7^Y"/BA=V3&CW#%2ACZ`<5LAI M#!LI=.$4G]_!/A,M*%=N6!V"*=^DEW="U$=5Q8)A41I7R;`/I4HAXVI9'PFG M^Z[5`.$C.P2?(94%U0NC305'P4E`J'55G"3!1\SE49V^[FL>K<$.4]1WHTP3 MC^;VCCMZK2[1V($WF8NJ$XT;93>FMB5^7Q19D[5N MPZ:A<&US^V$[GA^V9Q=4?WWUC0Z8&]CWP0(W(U_O/2I%O2MKS;):N2Y][H[L3M/=BR M"VK;=%M83!(IAT0#.SC*WO<=WJR.[;YM'9)']AZ7(8%8`D,"LX0$*D4"W7$O MJ;8D0V=EMQD^);1MIL7#LS*7<%]A?Z"V9(,.C3!4?F\ MN;72X4X@S7Z4`JH=@RO&],X=Q[8:])\T!P<5@IV:O<<=\:U^?'OUED_Y749P M;_>A+#QM+EQ&0$Q9#B,&!K+KL<&NHXN"&MY$^S`4]>XN,J*&WZ%]R>[!:D:+ MFGZU])$NH[C:((:HW;I$[]WU9&NUE;7UPZ/T;>M%7D*NPS'KWTAUJ)B,/FD@S,/G'Y? M-D%(9=$G7[[92;$/B7E,/H&1K297R8WB;1VE4[2A#Q+#@V2!5%-;VN^RKDB\Q)+34/-.9GVKLG](LA1 MK5./P\;XT8J,Y>#U8>A.%RH%)@AK%-?48`NIR[AI,2,[T[>361UP[E74OM%2 M)9P]$;C?*'(J&`&/&$8T)F-7Y]2IOD>0IRG$PD@+HBFYOA"T?JM1)V3*[ M.HE$/E>GG3U`^.Z7,`]'L-3P+_GA-5K_F2YN#O5BGC`C`EPP#NPZC+*TNJV= M#!97S45U;RKD'Z>^(-=QF;K-3*QPL">#025PVD&+V@>.;??#E=K4U%3?1.3Y M`H[V4[E29C4*?+*^,YA0ZX-3?E0P''CP%#TKB,M=+I5%6U=\[=OR!NN*WG6- M%OJGN$93,]JAJRO:&WX`TSZ\TK03L4"W\Y3.9T>Y$74]7#D-CU8@FL1360-# M72X&`]4HT&A7)TP\*DK,%08'W*8%/X,8G=]`V"M,UH*S]Z=W=AZ'1QL%_<2< MLPW1AN9N2L(>XZ$'T,Y@_Z2(KI0M*1Q2J9!2#JU$.TO#M*$B#IZR#N.^_5?,OU_VWU1W9B7:^KE:_7E*KUK^> M]GJ:<U*9)Y\&$7"^?'BC!FQ[`1?4JU>-/H1!E75 MOYU0&XNJ2^KXU?T#@?>6H8,Q<$^OYAD++9,GYU_WHCSYH!V_=G05M0]B>JFY3QAZ[5O,`WU>)[6E9 MK>DZR_+#RFX)8MS1O5%)8,]F>6S(M\T,8WYDT<"#NU#0>*1IX,&7471154E= M\]XA[\5C-4]1043S7M76BGUED9S M7Z)0M$U2@T6!0_$8.GZ!M7L8P3G)'DMF2WYY1FA,GMRUA*/8O/Q`58BK$<)Y MXKK"PG17DPI!G.LJ1//$U:JFA(/W5IU0TJX:BM,;8:]079?U-9+J:B0FU74% M#F"JJPE.(*KK*DD%W]A*4LUPUB.IX;`08C`$!!#>NMJ)D_E-8F!\?!;/Z;H: M+(/'EOH8B52Q@S<$38W+V=T2.\^2TR44])L5'EU2UWUJ&L).\.42VKU%!@?E MC75*;4>&25Z;4U+@X:F"]&`C^(5-TNX1<`CR5=A(]`C%M\6(/!RX0;.;;\ M&VND7+A#)763]6%4P&,,VF&9R_?9P M9\MG$]K<8;KW(KNWL2!X?"$VO+FD?/FS[W8 MM=W!PY>'"'V3/:<[%03UV2(IJA-/XB**JN-@GF#*EP6[;[@W`$ZO?'<+)A`J MF[JB$9`D(H[68]\'],EP4?]*: M@I-9N+Q?QI]X9^)D_6VXCG"'[88\]<[&#C4:Z"[@4ZJ)/]WFV7JH>C^9]!,W M_D92`U>1%**\WI))/`<@M*@*IEY1'M6\L M._NI"XWY%^1D",R"$PX/DX(#X6F`[.G%)LN1R_RF:7'MV*WID MA*(.@J//O8G;);BE_"3XI?=1HZP^0I*8;G!O'!VK=!UU8$JZ6U7([P95A^A] M6UA=\)_SYK+)"*/$'TK8$U-!CCHD>`7F)+QHL(3W7R?PI`TV$!5.,4NI(1Y- MG("VR8;[$#?9;=--7Z@<5ACMM0K%C9N#D:0ZQA[?\J:B'PN=NEQ@FC'AAJ=1 M;%MM4'&I(L6P0G\C5)!B9`L8"N"Y0T&*J2+%/*8B)96=LD$ M&S'<1$QJ#:N$.PHSQ`HIBJXT5Z;`L@4A9G>O8E=3X7QK?*L^*`1)_9@,3\9^ M%$(+HN>F/1!23]1H#;^+5(E,MBFI]J-:7:OVHUI]J`Z@VD&KW4FT0U093+9IJ0ZCF`,VI-HQJ MWZ%:#&THD1I^(6GW46T$U492[7ZJQ5%M%-5&4VT,U;Y+M7BJ)5#M`:J-I=HX MJGV/:@]2[2&JC:?:!*H]3+5$JB51;2+5)E'M$:HE4VTRU:90;2K54JCFI)J+ M:JE4FT:UZ53[/M5F4&TFU1ZEVBRJS:9:&M7F4&TNU>91;3[5%E`MG6H+J;:( M:HNIMH1J2ZFVC&K+J99!M154>XQJ*ZFVBFJ/4VTUU3*IED6U)ZBVAFIKJ?8D MU7Y`M7546T^U;*IMH-I&JOV0:CE4RZ6:FVH>JN51;1/5-E/M*:H]3;4?46T+ MU;92;1O5ME/-2S48W&>HYJ/:LU3;0;7GJ/9CJA50C5"MD&HJU8JH5DRU$JK] MA&HP3#^EVL^H]G.J/4^U7U#MEU3[%=5V4>W75/L-U5Z@VHM4^RW5?D>U_Z#: M2U3;3;7?4VT/U?92[66J_8%J?Z3:/JJ]0K57J?8:U?93[76JO4&U/U'M`-7> MI-I;5'N;:J54>X=J?Z;:7ZCFI]I!JAVBVF&JO4NUOU+M"-7>HUJ`:F54*Z<: MI=I1JOV-:A54JZ1:%=6.4>TXU4Y0[235-*J]3[4/J%9-M1JJU5+M%-4^I-K? MJ7:::A]1K8YJ9ZAVEFKGJ':>:A]3[1.J_8-J]53[E&H7J':1:I>H]I]4^XQJ M_Z2:3K4&JEVF6I!JC53[G&I7J/8%U9JH]B75KE*MF6HM5/N*:JU4NT:U-JI= MIUH[U6Y0K8-J7U.MDVHAJ@W/E7][G?X6JF.[4[!=L*4/KAYVODD(CEVG;UW] MB#=V-,$ M_['=\6W+O'M9BF]^7X5_B_^$$J9/6]<:MKD^=,0_UB](7?< M$YO&0,0HDCPUS^U9Q8-(1];*M>LR5S^,G#DY&W(<\?#6BR/7\_@:1Q84.Z!D M]=H<>"$&PDXT.><)#X]-UZW-=3O<&S8X5JU]`CFY$!'.9C(9B,>WC#O;LWY5 M9LZ_OD>#TC)SUJ^%=VX@D%V=F;TVP?H.G9>2O7K5WM6-FE@2!WKUS%5.RZYD'S0:'U*[,A/-Z8FM9]XV"#9X'.3)_D'VADW975T6ED9C'M^P'G'[?DO0CH:A4@L= M1:?1!=2"#'@`'HV=>!%>BZ_S_^YX__`^DWQ''>P\ M_[_\6XGP".A;&,811L5@,$AP+6DR&\TX=(MF#9@B%.I.KX%C.K-([SNL&@6? MS(+R'5:\V]^S<.3?"N]7(L?("/;YV&#VN2R*?9ZTL\]?#>ZFG>G\QDA)8L!9 M;K.+9U%D$OM`:$0XL/819,5=>%2PP"P2?S'X%L;?-O@)D,Z$?VE]1;X;[_8" MZ'_5OV_^'7U=V,CI$'I'=)5SO4':5,>M/MVRI\3G(.+SS@#_C/`/HD[V8BH* M@W_A79(LR`RK=YT'7O+K9M_8]>\\R*D!.7V!_P"T$`#C>NY!R`XCEPK_W&#R M8!036XDD!T`9D@8!_`I)D0`[1:Y0U,T4A2XD]0=(1E(4P!@D#0,8(.!5A,\! M9"%\!B`)2[$`O3'G,PBX).I^&<[K5@MX(XQ#2AB7\GJ$-"["A!9:I%'A)C3+ M(L4#3!,P011>CY"2^YE0HT4:![F/1!VU2`?,)O17B[0/X.>"@ER3UFD M70!O6J7D>TWH#P)V"]AIY<(66'FSTP5,L$I_!O8'K)(?(,XJ_04@QBJ]`S#8 M*I4"]!'@LG'VP3;.U]O&=0FS\=8_MG*HL_+"6BM7]XAH]FF;E`1\[]JE_7"W M_::`U^S2/H"7!#QME\:#3`\`4$ZQ<_:'[;S9%CMO[[*="_M4P(="BB9R94+* M4L05'"\@#'$26*NLSH)Y"R;,6_A"D)P60`3E)D$Y!_/V$@4,QYPDTRK5@UGG M6Z4Z@%E6J=K,[5(%H%BE`$"G1?(#C+1)*:!2E$W2(;?5+J5!+MR83^LPF MS872'_A. M"3B(I%*`5Q`7MD<4_EH4_E3D?BCJ'%C*!'9-P-\PK_,+.(`YPZ\QI_0*&"]A MXQ034F5I,U-0D3Z&KL0:I2N0>\0H!8`$7O"68L[V8S[]@%$Z>$^\LJD/)SD=MBDHY";HF)6V*R*'28 MI&4``^'J`B!<%")!TFZ4Q@-,"Q,MA.$K`"UF:1047C%+(P`N"`OP(3O^,(=-4SP>H,W&ZUILN.\/3:C)AL^L@SEOPZ]`H6[#RSU@3QM. M`+YZ&RX'AO,V_!V`.AO^CQ^R>]>&GX$ZOV`H%7!`U.T7=?ML^)>0VROJ7A*Y%VUX(^1VB<+G!>RTX0$`1:*N MP(;CH?5G05UHSRMR6VS8!NR;!8-;P$91M\Z&ET)NC0UO`I+5-GP/\#TFM^.,LT,6*'P)XWHJG9S)?CM>N!EVL^$>/@RY6/![@ M62ONMQ9T$;DM5GP(&#:+G-N*[P>^C2*WSHJ7`:RQXC9@6&W%K6M`%RMN>@)T ML>)?`=\B*_XZD[D\'`&09L7?A?9F6O%$X)MFQ==6P4JUXBL`R59\$2#)BNL` MQEOQ!ZO8Y,,5`/%6_%>`459<"C#"BO>O8C,2[P5P6/%O``99\4Z`_E9<`!!E MQ5Z`2"O>#&"QXHT`9BM^@A'TH<["]?S0PO6LMG`]3UJXGE46KN=1"]+PJ^74+/YX6>.X6> M14+/:6*MI-CQ/1ZV,?!A)Z:\,?P>1+AED.DR_)AI^#R3?>AJ=";IP-?P*S+MZ&OX99-\J&(P%&V'`0 M^&)L^,_`Y[#AOP+E(!M^'/CZV_B\CK+A]X`OTH8;@,%BPU]"H=F&WP0^Q89_ M`7Q(4'98<3+PM5GQ*P`M5OP2\#5!#O@:K;@62'28K)76!H(L%/`C[$TR,"WZW>!9#V6-D.PL%N6/H3<"S(G M*1*YK2*7)7.9RV6I/\`"68IB&[O,I0R7N4I1@M(@E0]DR0MP3):V`%`9OS$/#"+C5P#^+"B?4:3E(.6,(JT$V*_P*&&A M0:H&F"I@@H`H`<@@;6%#9<2G%\#8&OGRA6_$L!6WRR@E0]U/C5(20(Z`?B;I M?ECHO4Q2-,`)(X<)$=P7?$]`@H#1`D8*&"Y@:`2>##`X`@\%J`G'8Y;!&2$< M7X`Y\4XXK@=HL//_^@#7SO[\AFD2J. M!REG;$)/`:_8>'N[;;SUS:)PM2A<)@H'2'P<+F"\#>K>P[SN+Y@K^"KF"OX6 M<[Z=@L2.\""1&X,PD5`,MC(&<*,7!@V\H;.*SAJ)2QM M!:$<;KSIFY9@<$1)HY28>) MD[28.,DQ$R]\1Q2^+@K'BKX/$7WO)_I^QC1%Y@T5R5ST=B$Z1XB>+NHF MB[IQHNX^4:<(*)4X%$B\[DS#^(Q1N$Y,]3TSVM6*R+Q.3_6%!^:"`!P2,$7"_@%@! MPS">!,*B16X@QM&0.X.XE+\AWL)?$3?YTR*7@WA[F8BWMTA03D6\8\,0#F/" M$.[8",(0]H`3Z(OP[)]$[H\&WNQO#+S98D&9;^!:;Q7PE`"/@!\*6"]@K8!,`_X,=%EIP)G@ MD*8+T9.%Z'%"]'U"=*=8TZUB@L&;L*SNO%CO;XNZUT3=[T3=3T7=&E'WF*B; M)^I`S@B]9QK'Y8((P_,L?0S?# MA"3UGX[OA>ILT'@*L&39IX[W`8),\ ML(]]99/<`"=$KE3D9MJE)B!QV:66>YFOXZ'#_1'\9)H0P6.-C`BI""@714@% M`"X!R1'2LP!/1D@[S3PJV0_MS8$K$P"G@#H1E61C: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDcbS-000fJIC; Mon, 22 May 95 11:53 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57030-1>; Mon, 22 May 1995 14:51:43 -0400 Date: Mon, 22 May 1995 14:51:33 -0400 From: Jeff Lait To: FE-PCX , Directors Subject: Poc III, part II Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here's the second part. section 2 of uuencode 5.20 of file poc3.zip by R.E.M. M&82E/D:8(5CZ$"AM(B<+@``DW<@F.V?8)4C2)1S^>XAP)?P\0)0B;0$I%D7: M',9L+7D![`;I+8"O%.D`0*,B[06XJ$@OA?'M>B>`ID@O`AQ5I%T`AQ2I`"!. M\,&I_'EVM1/&FYTA8$"8=!XL\:69*_&9F??H`P'OA7'8+^`_!/Q&0)Y@/RE@ MB95?(DCA>.P<<%WAN&,RQ*WA&,-EARTO&0_^"?A6`0/#<>=+L*;#<=YN<%UF_/`+X(($/,O@W]W1 M=GT__^;?W#GS#GYOUA*\>QA47OO4OK\Z,EFMZTKL887V_:'-63Q M4GAU)@TT-4:K?1A#R6!&R,F@V@2Z+8(G9(PBVI@U9C=KO:0NVG3H,:;&YV// M%=8]=]3BS9IRI95Z/1$R5[Q"QD&+]^+V[AR*V7[E@.,SAVD($_?!G(5JFZ]< MKKDES2CEBNY$+U>/-K*_(KO="Q&9XO^5=VU:MJFVI4J[V7\4;R5:J``5>ZW(_.UD9D8&;QQ9OIW,PLC@1:3( M;R>+9&21JBOJV\FB&%F4ZNK_[63]&5E_U37HV\D&,;)!O@J'L&2/]7JLUV.] M'NOU6*_'>CW6Z[%>C_5ZK-=CO1[K]5BOQWH]UNNQ7H_U>JS78[T>Z_58K\=Z M/=;KL5Z/]7JLUV.]'NOU6*_'>CW6Z[%>C_5ZK-=CO1[K]5BOQWK_,^O!.X;I M"^?`>WQ7_57PHM_!-/8NXLMR\S1/R^*NNN-JLZ_"S-^*U.GI4&AL[6$$WXJY MUDSZZF]WYQTLGZ[HOX>"X:&0C(C+7*;;?(%(XK+X*B*G>VB7O`706#,(C5:S M%9#;4`-RU71%-99=CBS3(V7E%^R-PPKX]@D,Q[6@?6]YI-SWJ4'YY:Q1?WL[J<0?F7.4WTW6A(7R;N,/??$Q=Z%2=%R=>^OPD-NJ>"1 MPL[4Z9[/%R_-6`$,8D2G>X[Q9F]__[7K_T["WODDSB:RH(4L;R./=JC.%A65 MU4OJ@B947914E]([@?I!6T@7?=VAD*W?L5J[AT" M.GQ;.Y#;5.EL8PWYV<]-Z/WAI=\]H\)9%HCT,):-AZQO(ON$+Q7Z)K):U,44 M-((!0\ZV_*UM[$<=MHXZYVP[;]UE1O#EN9?@4]\/`LXM;P$J9LP^C)?9LX5( MP;_=189\4\8^+N,`D['F3AGQM\LX[&4_=%'K'P>%^@^B[J88H]AJ*P0C+V@K M>*84"(,7*PP,<87A'8!I%8:_`,RH,+`7FQ^M,/P9(,T/7V!'NKDW&("-S6&6 M3:C=S=*Z=->&V$]<;'6HR]L.\5>6V8?^;`0?BK(+$GFNPQC_-".4'[@&Y MR?7,RQJ7LI@5XM(5AZ6UL<6\=_P^B^K6T.T'1! M4\C9!/H6PC=S?,X.)?AIOK.I'NCRG1W,.03?%:)5IWY3^SMT8K\_4N#L2`@4 MPD=MX4XV.2#S#+,W+#3F)&[CZUZ&\;PG+61!&UD.*U%GFAT:#UWWCV?&_1A& M##A5-!JA`!!6LTRR`KF=D+ODF[@/ABG$NEV]AR5]$_=W%US:PY*[66F)L"H:I8*GD_I#T M;6U"]F>_PV()5A0YG/T6#AOQG=Q]2.H]9>U#XLIKVI*)\_Q=2V&!K9TO]$TGX\@-3GMKA7FR2!KVMH`CY&65\_`]+81"7*[W,&U M2_C*)G5NU%KG)<8E@][<&X,OG@(,#RW^CX;HZOW;:U'G@C564^<>QM=^XGS@.K<=ZV..$M59YW]3\Y].P);;5U)5OQ\ M,+PK!VG5>1Y2^P4)3S*278R$YR"M.I^7G;NZ!Y`Q'K@E\0`C?[%;X@%("\;2 M6Q)+&4C*=];6[IJR^HC,27+_7>7./Q;)?XEC$O$5.4;Q)T2 MWP7ZVR4Z3S+/(\NG;YR62^N%A'NPA' M@DP85#WDU&5G?07*ORU="3:-V.'_0A>O='=QPO^PB\%IM^7*_@U'Y+^A MN7W0;J?IF0__Q^:#V)ZK[E3V?V<,_G?&\MJ_Z=QW;DLO%&GH#RXO=%852+?5 M1?P;/'WCKV>&JFDC?+/KP7XOV_6O1?BBZ MZS8\2_JV;=@K?P+?R6]-W>X] M&9BJ0LXJL2MOC?]O^24I*`5MMR_YX%OJ`G]9>^1-D\)*()#S#V>_4PF:LZX! MMYGGXQ&H:_2=:/0/FOG"_%!O-S)^\#IU9?6R[I'XF;G2>:E["EX*<;LZMO8_[&`;QH)+91?, M\H)&QGL#>(/G64H!3?TZ?*3IG28F7M$?;H+3NK,IA=T[B./VOTH-MQ?_AIWL MKS*/6'Z8G>OY\KAV`XY2)"U2/R,JDN^H*+L022+U(Z**K94[J]C55U-ELEG$ MKY"RB%0C',7(E"AQ=U*$^=&,3.G/G0(D!K$F(=U]AFU(#[%=HZ4RN7^7)'T[ M6*?2P'J$T$N0FL93JV'_UV$_'0@B^;?4]=`7(?8S_9-VSP<"';-KLG*N8]D% MT[WE96TF;)C)KF=X]<^^ODMU&M3XV2^:ZF\+65&5G(6;D=>BF]

<]0WGP0+ZH<]Y/LU_@T^3 MCPQB%MY^?VBTOV3?M\#7J)`*T,O@:_LPSY00:"@%Y?YZ`'I3O$V.OY1PKB`F M)LOWSP[2Y@M9<@U^-KR)!M;;O/ZJE1U>=ASSN(B5E:A6QA<*7H+-$) MK\^_P)P<:2(G]&=`&4)W!#S3=G/Z.5$3RO.,I`_/3#>#I"IO4@SLTZ1)_]`* MH@.>/I!\ULZ2[M[QQPHL,0TY,%,JE!C4>NYXF<516>[>E@'/9P& M/4SDW7;W5D=W=_)R=R?C+Q4,9\HN9RJ"4R&5Y#0Y8RRJ*PDL)%5E#=+5EPNK MO)_*5_>N,)$V[B4;'@5=&K1(A+Y7OF;H[\_:C^'D,R$=K(-RK]$SG;HL4N"? MTE[X>&MG86;(>Q+_[D?]QYP;;9R"T)EC9]JZRG_W=,O'9]H6+:W.*4F"A?0%&3.]*>1.K\F/YSU64Q_>?I[`=_ M?4T(M/@N6M M*3$C%7 M>XLU(9"ELBX^#,P--T1C]AT[(`&MC'"X_Y'E`W4DST?0]7C1=5#!P"^ZQAHV MPTI*.+;/ZS$<9-Z'7,W_E"WPTJ0[.O4"&$GI;K"K[,=@A,)U,:/(5;-^IPWL M16N@#UUV@%X;0;.8)'!3;7I\))_ZLO=]ASXXX_P^7Z'71;ZA("L#1O-K*0E!WF6V4M;XE4^-I"[L&'F?Q>_`;WS5G@8T:Q5;:'924J]`\I<`2EYR:"`LM MYQAKL'!UC)6`Q)$U^.\@3&D]ZO"`;[3O^`';(T%SW]'^/()J*`!9\^;"N!4O MBXGR7V'!UGQH#_IZ4?^3G?M$6*#^`-B'SM5;0GP'ZK\V4Z^\+*HE$+J'!S0LGSY\Z^U''U.].C8L;^X!CKB=[]/RU MZS,=N4_ENC/7CW&,>'RD8^J&C4_EK'UBC=NQZBE'%\/T;'=F3O9*]]H-V2O7 M`47.QC&.A`GCQX].F#!AW!C'Y'7K')PEUY&3F9N9DY>Y>@S$6>(W[1_?D(UN M^"YUD(MD\'@#^[V9&/C,\L>@K#WQD#H\=_*TM)&!TGAMZ.^70KY@^#)&53:R M];U\=AFL1V9-7)3BF>0-QA?4E:*TK!(#8XM5!R]C3Q)H""R3?Q%!Q"0DEP4M M6S#O=# ML/S0[^?RWLZ#SQ*:%5OTOWA[%[`HCFQQO'NFF6E@<%`&145!,QH10R"OA8`R M@."#:'A$!0V:S<:)FV03%[I1$Y4F`W%ZVC&Y>Y-L;K+)QLWFWB0WN7_SO#XV M.C`N"(D*F"A"5'S$]*11471XROS.J1X0--EO<^_]_B9-5]>I.E5USJE3ITX] M9E)[%M3MWB685PPIA-=2?UOG[&8B@?W51N%,1TS==,>#OOX=T9W_Y5SG$X]9 MM[H!_[;6;=6<-JWSKS-<'WRP\L%E>=.MVR8ABI@+DBXD&O[-?OJ9Q%_Q>F$S M,YNG,\'^_Y#OA;]\VX=96?#^*]\;M5(\:Q7OR$'JS[Z'<"H:"]^%A<_9AXM5 M,3W";*PUS8>4]^"Z9&G`+GS9ZV&PBW%U_J>]$8:[S@_F["05=AG-'>_,0$SW MS@K`[HP=>W<(UDK^#;R4V_)R=E_,0C+2H$*MHGNY>+3_PQ2*[Q,OQS0N0*U? M``M^N'Y#\M9!IH+/'C@XY25KW#9"+S>L)N=.WM82Z.(R;2Y]L<7Z`*ED1HQ/&IO44#HAYA@F.4P?<^9'2Z5L MTE'^!_$Y4XQ+R8ZI%I\+]65$2(M96Z^A>++81=>*SQG$<:).6LF(JQCQ059\ MCA6_$I]CE'!?=B1HU\-2*2-N9L5UC%AB`#TXBA8[8+B)PL5OCXZF;M3S,D`O MPG+]>S1WWCR`N+OTJ$SXJ.3G#+P6LFOUHBY?6L5(9:285+'%2.D@L!*YW/1R27F=4MCFB2H>79D6M?E!4D'2J9) M^1$Q];0KJ7X=<$CLTLZ1QGFK:2[.UNOC6.',`'UL/M^N(M:J.,-4C`;U%0`O MQ2,M8Z116WK%;JT^J8,/U1I%8W()UA;(,J",]F5$BDM9<3,CKF/%8T`$7W8$ MP$O8Y.S04JV8'9J<;<*WB=`C/T\*1Z,JJ8$/E/)8D7Q(D]#\2FJ&J'R(P@]< MB;>`:<9I89D?QTV8GPR:*!))4=EDK-B/T[-TLT1)$VRN68`@T;F\6VR0%K+R MOX+V$^NE;`9LT3&2%G6)E"S6?!:P0W,P0:D6#^A`3RQ0AP,]3//S6.4C=7;H M%K^57T8%38KQ5`%_DEJ,6_#M3(="C)7_229/):#31TE;.`M?UH\*\Y@RD:)C^(LXR,".(E#07M^"-($8\3\749MAPF%S'@B?^%R$K+\&).A00J!M0*S*7Z%IXO+/&V"`V([- M2VA5`I.JBP/!.`9RN_A.<3F#%&_E`L1\5M&IW/`SP+D\6M+8JF?5IJL3T_1S MZDOUU:5WD!H#`Y;WV^19XO(V45/+:+!&8@/R+F^0<=QL*<\L3:"/.*:A2K&Y M&:%?4SQ1Z&?7C15F/Q2`/0*LDJW-1JW+\@YJ]F2BW_D`20.($ER#DI`C*S`- MA$$9V"L9S*(;:$O_/&W'@R'@S&%M"BM.&"1P@VAT;;-9PEN[$RW%0)C71E(M1I)S6?$@Y.&=_:=61* M,Q#&YF'`R#*`%<>]#[FD>\PVF4GJ6/2ELF;'B>W@[)F%NH0_EH>]GY0%(*(5@@*Y/ MJB\)V#U`A$Q>@]MBP`Q]0W3;NKO7O0R3TI=BJIWI_6#!)C6LJU`%$*DT1GJ" MK;S`&9-:8"JH%.M)'^%_!`)-ES3.['ZZ(:F*GXB$JF'$>\ST7=(LL],P0W37 MTD@1)0K,]43C\W?ZB/B)6NBH+?*_]P\14%)IZ$N/`-KYR2B77O;3#Z>X*LOS MED*&4%NU5CC3#Q70);A6@G#_/%$#;-6LHI=W0$DP5(79JE.2PXKKI7O;@;A) M5TH"Q"N@U\4P5?D`Z/]3%5`8*(!77&2)?27I0?Z)%`<"[+0P"_BK MF(>[?P$7(Z(?:8&8PXHY!BXB,2<:O%%BC@EB(L2<2*S0'W0('0 MK^7HS,`+7(",/ZGS1NO9XW>LARG\\8OJ?\M7%.K=-0%_`_9K:P(BD;I6(SUM M`EI<-O+2@0_12!O,,.'3V-R)X&3QBQXW0=Z&*F);0#WDGBZ&31>S&1EE55FO MLH7B)UIWZJ=-MFZMVW;<&?ZW5>1BQ!W,9YT'IR@/#;(N2IZ'"B<,ITB'!PF_MCO76G9MK!*>(D$[9O:T`$=BF"7HLP9MKD M45$;0YWA#Z@UE=%5IX0/U=P8766K8VRGKQNG5KD36IWAWQ![]UY`:0O!,&.; MAJ_K&0>G@*P2:G*T&[CQ-NF\?KKIY5<0[Z*40#Y<;3$UHL7W@+5GL&Y'XA-* MF5-&-/YE;'QH3),L#;8_GP]M M^*]\E$-FZMUH8[,2H.W:B MYP@G>NWWX_1ON7OG*&SOA9WXLTWR6*$WAV<^':6$"KU3BYE/PQ2]T!M= MK/DT0.@+*]5\&I;09&^1GO\U3K^Z(Y0@G(6RI([R(X-54(=KL3HY8",D*P8E MA_6W=0>4)8CN[0V8]:R&;G;,I[U5%GZ2_:!PT&)?0X-"[QT@<]@@DDAX0$M' MDY#$O$2TIW#(`K95M8H"]O-%:L"]L`S='U6@D'\0O_HL'2PO3RA,,.X3]?`L MT^"P#-/^T63!1O8-^*NH:$%CXTA<2`@"EH3?YP.C_"BQ`?P9+Q+S"6?AQ$EA M&QC6.!SVI3!Y;1((=D:HZN(0:Z0U!LQ9(;N.+D'G@IR$?*NN]'$1#FN(<*[7 M?M8.[Z\8L<.^,D0.GPM.G2Q#-!>P&VLB;38$7A(;Q,T&XE0`C^?W4G@*&EAD M>)'?A>1)U26LV!"S7VQ#TT,%TPWO6.`E;YN+6QDIF+YM[T=7].'S,&95SB4; MJ9;C;"L_3R=6S]F+OPDV9]]DW(C79V^`R8-)F*/A@A*SZ'4!8J/:)35XE`?XMGM^.<$[CU[ZAI#&;G&EH*)]-0.:81EKS2T$\'YC%L M)*N2<0$!A&NY="^FH`^(Q]YI`-[^M!-7"D'8=IS,@CN#ME4Q0.EZ\!>!_Q'+ M"DYD,< M!;30-Y5C$OMXVN(LH"N]7"!NOQ2;TY6OP,55J^:.J&CE9@I]T=PTH2^0BQ;Z M'@;7P'IZZJV9OH%,#4!!YP:,GE)U6N.,'(5F=K`C0NRI:.49^P1EO"C7:"A/ M)LB?(Q1BFSB]*'ON0W%\"%QN&O&`VM1"U$/;T084P_'O\D$GXBVVCM%Q+QE% M!@*-E4^C95BWN:"\"NT9,KI8RT]3'3!2F(%#L$[^CTQ^Q2A^-<(4A@E.NOSE MO;B[%XM2@N4=Y`,UIJH&;A,&-,5CA`%VW4B#77-&-0](;';,J01PU55ZUA*MCWJNL+W%V5K7S`'IRK.,()S7II M/OC^<*0CKZTZRR(ZY6/(0*JO.LG0]M1[$@&5*GG@L1!/U6:0U;ZM#YM9QX/A M":U"S[SB2:4SA!YKL:'T/J'G<2[2\Q8*6L]J;JKG91+*-#XO0:!TC!)N*V/! MLJ^=QZ+Z$CP:XB&59MK^SHHS<6,&V,.PA1^[7AGK(PF1CHYYX>959*C(@>'G M0,X3VGQP^H'^- MQ0Y`Z%,E#ERJJO;+SQ6/>----)_LB*_PA5%Z`;9(?/AT9" M1^MYG&>%Q'A>.U_I%A+C.-KBF)!NC["`?'N1S>(14"^"524=R9U"48DX6>KWJ;_0J*4Z?9B:A0,`AWVA$(JFXJE4GP6I#1N9??W^ MGW+4^CHI?T+?892BYL*S$)Z<1]%="Y,# M>#\&SQ/PK(5G/3P"/'8__'5X_Q6>#^'Y#)XOX:F!Y[`??A;>%^'I@N=F_$L? M_ MF:O5]VZK^A[W6_7]'#R_A?P+`/XK@)V`)P[R)@+\GB<`'\"?!?AJ@)<`[#H\ MOP;X4H!O!/BG`)<`7N['/PG*+@4X!_`/`=X$<>\#_&V`OP\PR^-JNE<`_C'` M+T/8`_!]_OR_`?B7D/\+@"L`#P78=7A.`CP#XE]X'`]>4-0Q@'<`/.M)/%\! MLN9_>GY/4>N**6I,B?I>`7'Q3]V`CRI6OXM*U/=:B!L_+#]^OUJLAO']/+S/ M%]^`#WZ_5Z*^7X;O`C_^/T/9MT%<-3P)')3!0YLA_CC`Q_Y>39,(L&_@V]:`D%?7F?1`&R/M"5.=)^FRL2 M4.0L&,+Y0C,JN63C;+?2!]S`8 M^JK#"H:-QJP7^EU&VPX$?^?H=UW2EI_5PUPLZ-1_4W$^TYM;'\9I9Y7()TJ= MCN]L9Q.#FN4!,%N<=W2#>I@C;6+*?Z`282"X%.Q,V:?UQ?G,;SY0!,B@U'7; M.'/*=&Y.2AP7E7(?=T?*'"XZY3'N5RFKN>04*\>F/&ZLQ,7*+*41R232 M4K@C*)^Y*6.89R7DL,P!OC!66.G?&1>T8S-0>(Y57,+$6:4_QY&/*44L?MQ' M/@+AP_C?^TZ"D8619U9@9/EJQE>+,,9C^'F,G@YPI\UA,YDY%9D4GP%K`+K) MMO:GK%L;@:72-:E_%SI9^CO?-7ZQ7YV6P;H3@$B"X])UZ>I@`MO^IZ+TZ#R_ MNU5;-(/\-9._T>1O)/D;(=6[I2OP6W<.SD+\ZAOL_\=[7]'^M^8 M5PV9AD*A_K=!Q8I(_`'S8"!Z,!`Y&!BJA(K)'PP=#!C( M04%O!Z(MAP.>PIE$M'Z-C3]VM4@/A<]P>71'SFA;8('T'7!X39=TSB5/R>>! M+,ZY=T9"&-DO?PBGG.;X5I?ZP;4W@:O&C0"_=P,L)X:#&,T>&,*\=1@L$F&' MKP_!UMZ$=L;(4G,1G/F4\R%(@>#`D>"[;LJ]+'P$..RFW(E^,,I>V\_(W@B) M13R06:Z?`+5>!YMZL3"Y=#SZJW0>ZV#$:G_$*&C7+K0P)NNL6UVX2+FMVKJM M6;K>^:X^RO,K2#[=*NE`C#,IZS1*:YU-:7F#,[P-W$-SQ"6E2B3$:#`FY]?^ MF"!GN,D?]G3U^K%+IZ0!Z5KGNU*?YRS$03_)I*9;H?QO>X?H:H@829F3HT=0 MYL*XD>#.D80[=`,L/P$D]SQS0TX^&09;C##Z!NS5F]`N'UGJNG$C^9$\$EQP M4VYQ)+.3;LK]1-C_D)L=X,#RO-^CJCG?W;X2QE>BPX)1X\!$Z`QED-\E?'#TO]N,+U93>_1]!&J3(D>4\O`P^"<(7ST2GG)3$;N-MQ0Q M?NQ(*O_QUB3>\)%83H^^)E2$0/;)W"X5H*=D6]H6W>A+>/<."GRW7>M[T+=W\"! M[\Q%T`FW==W4I]6D7.Q-2:&K*RRV20U5&FD0RY'.)GR&"" M@;"1"9@Q-R4X<2.!O`%W^FSN'H9_WS#H"H2.&@[=?A/RU3>7+H2-%(:Y-R=8 M=1.&EXPW)9AS$X9GC+]4G`@F[/R=T'3/A]?^8>=_VR_@\C)(+#6\EES-,;!A M14#*CU`$CUV[11$\-IAWXJUY/1>`:YX[K_TR`2;57H35O@8[E#SO>V\IL\// M?_G#T:KRJ<1R:B$UFJY3P*A/&S8A^:G'\_I5%:OSH3B5Q!\%JR0>$?FU<62D MO`A8ZR<5%2KHM6NCS6_4VVX\$A@F2<+,6S_!NLI9CX5M[U9#:V-LV[_ MCE1>S.0&NQ4#CB)/H)]L\K_#4.?1^RMP&@JB8=/G7'A$>`[!$P83O`)XWO1/ M]/YIPCBY.R-C7:*N-DNUX&NS6%^JYT]7?H%((HI:W8!CXD%`DKW^]6\0"67Q M+/OE2/[6,>YA0!*3_,%.?TW&_'(DN.T7D/REA:KSU^3@Y5^,Y-^Z#O,G>*'YP[>=H[ M5-'H!_9'PEP^!IZU\%3"'/X0/'>74M3?X/O$,W[%\-S$&UWM?S8G(UHH?.P- M-/+E"?]KN3-W_&/R>+3^!#\[4SQS2:6$;BUH/GARX/DC/'^%IPBHP,/3#^'` MW_N'&-11>$&$K4T_8H+Y_.`$\_^`3-^:AI'IFT'2WS3>R*^/_R7T&S;LD-Q6 MR.TY=]&O,!:/'U9BMO\#Z3+9[R6:\_N?5_YH^J"&0ML']1.Q?8AV^A_20!VI MY7@P;#QG_0SZCV$5J(7PD9^H$$%"E7E"+N*LIC:32M7BBT%(;2;XHF_,E6)] MGA\N8.,'1PE@:R]S\]`!D>,#;QYD(++ZIU)^Q/Q$R@#]3Z3LT/D);)7>&DZ> MMX;(XUEX034I1KW^?X,*!6%'BHD&FK85`Y7_J/;4@L[G_('K34FN4O@OU]#<:* M7Z088:ZHQ8EBAFK!20UH%@O6\GI?JA6V6UIA][[U#E_J:])1N1*ZKNH:;!.FL$KS6?EVP"X-D"H1RW]BT(4-K#6VR1I; MIX18=T,UI&P65UH%!68D4#.IGGQAN656;<.&T*!S0QD8DB&X$9O@Z9551P\C MM4,WF.'Y$;Z7YN9;I6+`YP5\>O^7M)"1)E2=APT_:UG<[4O)LV'`70%;Z?+! MJBAA"V&;`*;DS!%PEL($V[)"1Z0VWI2ZVD`%N_BHX";8C*7U\F%5%T,EM]2H M]5J#3P:W<)K&BVYKX\G@.CXDN)4/[*J!K1IEL/UER;(MAZ2>JMK0*E]H54\H M+,Z640(CJT*MVL/^0.QA;G()*UVR=AW_URU'K;8>2^DH[05KXPDH MZ:AT;561^W,JN&Z#\7-?U\FN5MM)JOP:&A&Q/J&'XF;EQ\*Z:G3QV&"7\16W MU(=?%IX)[HUMDJICFXP?N8,ASOA1@_&CEA5:=]A1X5MJPPQ,8^JJ!?=X&>1J M5&P-E*V)`E!72U>SK87ZW%^&U!QT`IKYH#7X`O>`<)WB1S76-AZV+N)2PUQA M325>:Z:U_#K@J+@/4OV`?>N[7WT>R)A>SO$%:SR0_R_",E)A\/P%RAL;FNSNT7MLI6,V<)]6N7.4F M)SKA'9P8?'_P>B;X6>@]%A97^J5TV&I4YBL+KB5Y^0.0ZF?%*^1F\0)9F`>R MD.&7A600GRD@/I.D&JO6Q8^%NR[H75=]A`^IE-GN:/%2"V M_)"OS`U90R!K($H>C7*V1&K_><$:%*L>?R#8QP=I@4O6!X.;-H"\UL%G:YC7 MNB#8"Y^Q/=;R6E_J^O'6M*/KQ.&]MHR9%JNB[G_&O7V7_9TM)U1NL&?DM%'=[,=MA7 M![*VY&K7\8D=$WNY,;;?R;2MJ)W2?A7&7[4=H_B+X.^Y+"VZ"HB"8GML<#[: MMJ2=DHX1A,$N;M8(I'XTXVR_.P=H9(J@6M3AQ^4I6+X"EM5661]L5$H"4-SF M0>/+QO',Q[2BLW:=LDJ'![N`-=:G]5D;3TE=('J_@*DWL"XN36H)=&P*[FG?[]N&IZA40L1NV,%"Y(&MCC5\><'@^CIIY\$B; MXZ#QBX/:>JE!89`G,&=3I2";Q4U54KWQK]7!56W!53TFK*V>^Q425L_IK>55 M5(HR!0G758UJE=<`YM$YI+L_<,[G*RBOAPI9R%]!F0;"Q()0,<#V\=9==`I\ M!_S!:O-$!SRGQ^M=<$V2A1NGU7;VMBLQ$"U!=<&Y.9D3$)M-.R\`0W6 MNHP?'F#)QXK"Y;`3=RFRB721O61YM+GJ[-B2<"C9&T!61T'>]+O]A=?X"T?* M["=4*IF"2BC8^&�=M4]:-!"8)@L+;)^&%],!;2HCP"Z:C]Q7<#][_>>#N0 MPP`2BJ,;^):BI0YU0*L!@3WR(^AR(N#`)^@]RG055=6/*B8D?L M8#^KD&OA%';!2MC@"T1L@<'Q0%7/.*P@Q=U>U<8*/3["1"%5&?4Y7H<*5`M` M2ED(_3$DP";K#"(*@`03P),*3Q1NQH)'#X\6'MS*#SPJ@R<5GBARZ@/`%-ZQ M"F`*-VKA@4J4/P!3N.L*P!2`*=R;@WN7`$REXA8`>-`F02Y!KCEA@L8%PPG%L-(Q?%%FNA(&/%&"Q$#C[$&>AYS%`),`*K2.(( MD@AKAK$R&D]K#B!CH"O5&2M"\;C0/-6_4OX@^%<@$_3?><`R@F!QQ'G7N=K& MSWM38X)IEGVCIJ)OWX3I?W\J3I/U9E_JS->>#'IS5^SNOGV_IV-?N?WV;6?[ M4OO7_.E$L7G!'_KW57VDO/PU_.M/O5+^QP_PW_5]?DX(OM1E2W.E;JOT(&MM M/,W'>],#!2[<6IL!OCC8*8!'\FNUZ*6#/?<82:G;!RAUPX'"6>%@&6:,LDKS MP%B'VH>@X9[!CLS\@..90)G'I1JWG(9[._(#@RZLCPQJVC!6#K+@1ZD%I_3CD>#!0>#P0!@4UTJ?RL\C)"0?XV M6RK%3Z[5$_?B/%(1Z\Z!5.&T$'0:"8H8\O+57!MG@?Y>QTH/,E(4CJ-[?:E$ M"Y"#EK("_G%1+RX#/JQC"S_7D&;.OI[*CY;F,;.O_B5>Y/62?O8;.Y[PEOX^ M=\];^:NK=Z4?^_3$7NPADAX."B)RF8=JY^0M_5EX(2BDV-9=6&Y5#=9A'[SD M5,BUHNHLC.TGI<["%?+*$941#M)2K3-\.IP+WH,K3_)CL*VNX4))A%2[9@"Z MWYJJ?PEZ8'-,`BU^`04BW`W@.84!(H@$6^@1'6!0JP MX0=EU@9[^/E1>):/9VV)L'TRU@61ST+D>-NS$!EFNQ_@L4WDX(H53JX`'/8` M@:+/(=:L]*QJG:AF"7:40I$6V-@3YEMLW&H@?2VLJ;@=!IH618GUPBBD@]%'HX1# MC![-B<7*M<)<8K10VLL*H^V*]16N@"4]`7;%=6+26*_U[N,;-%VG\/1=,\Q' MM^`\5VJ88[TM$RSP:EZW(^T+2BGI:H(YZA)H109>/'Y>:*AI.(^S43CWGL$$ M:W?,Y8V8V>_8S61W6)14ZVR`3\7H>P:C<7!C(0?.Y(0=-*_9$:",\V;HA1V, MBF`HY8ZY034W9K)!'602"UOI7_)D>3Y__:/H^H%]@:O+/J=RQ]BTEAE-'[[Y M2G>J$."ZT9/WE*Z=LT+SX3;&]\NL?V5-O552[6E9^7LP:5 M]AI,_`0%<_8=X.`&ZW/94N28#&N>5('4DB>_`]UOU2U=`OW\.[\$G[_\T;5A M4@A<)+T14,36$3LHN&Z]1J&D[MTH@V@/@9UB%9>Q1-CW#J0.["-B'MLJ/P+E M8Q\<2.6-T'/O[F0^YW7EJ16/G>PIG0!2`4,)S)JH&QGNA`R*8:ALG\$,?6JH M$UD7#\N3.IBG#[S0T`:I7FHNL$H=RPODB$[2%Z5#Q&J^C!#Y^-5A;=J#NLT9 M8JF$/K47O`+#"W&&3(5H`%6)WE2[#7^B?>V$!1(H"LI'(=2SVX3+` M3#[O,<,+KT"`:3LKKU&C"X?RYD,]"V%X*L72CDE5L@XZ^U"Q-UIV9=^NL\\+ M)_<\G+&:E:>B-AQ>@Y`.M6VWYB,4$3X&BESHO"E3\Z5;&/I28?X3E>7)K]8? M2GVQV_5FTI]3CQW=]WWVFHPWX_^PXV1J6>3M'Z3&WG7L^WV;_I3TQ<]JL=[^J:]GWP9?[:\IJ2U\\ MD_K'L[W[]VRZ\J^>?2%^?)=2@[]XA/Q_;=\@OM[407P#PS"C@8$[@QGX+P#^ MTU%+4!E)[7B!2[=?/(?,=#32-^(MR417[0/ZH%;<0[0B45B/PBZ0X0I+ZEGI MG0>CX\0<6/#WJ]@;`]-OP'%;,%\ZZ3@KG-5HW&9]#IQHCUPS<*NZ3;JHJENL M$(RZ_KJT;1H_=+E5M[K,DMD/RRQ_5"<]ZQGK+CR3>QR2LIOA@T7WFF'10CMT M+RFS?G*S5"]?@]XC+9+)6!%[W&D0G89%'5M` MCENT@[<-6D6^OR`%CJFIB"9#?8=GT-8YPU^%'-I&N9O<,DB*Y0SDXBNP(?A^ M)7"H:&E1.Y[E"2`N+N$ZS1>`M`E5&L?Q`3>0B#,*IQFIZ*JT2,UHP$_L.YB7 MTV$FV(11$PKSU`E@>(_USU5'^;TMQ,>@!,C9PV57^AX'%1A38KWDKBQPE^TE M/?7J=?6#;%+_@7R\%/[<_*\?=W]0Z4O]X:CTX]FJ5R1?ZC/O[W3F=OSJ-1]1 M0JB0?*E+B'(#^?$BNXBU0?;V!]K`V."U8&EP5F#0A@F+U;'5KUZ1TP^VJYPF MIBX'UY_]]S]:H*Q-O='NM1>Y1@._M6S+9+4N8+3RUZVC' MJ^U[6O<="[R1JC=5/@:$W#4AX-OS>[:`0-V M'7=/HZ.XCC8&10GW?>J'#5<`%86.DN#E`,KK310IG8$ M/T[)53^"-87:K4@=KP:G@Q$@8O<`"Z99M6"(_P?VMUH++%CYC\.KM]X+\_4N MCX0PU1XU=KHX?2`4MM4\C=XQ?IRH'>#.=S84ZQK M_+&QM?$43-+0/(:"Z\$_>J6G\60Z-WEAEW=Q:EC*JJE^;F@"=ZA/?GAM8"[\^2 M93#USR>C"9O!,+:%;DB?^'?;8 MC#UX9X6+RT\1N`?C70E-"74)K9_U'KS3.MNJXV?OF#HL!@XLS?J"WC$9(^SW M\GCOMABC70;F$]HX ME5S,8P_GH-1X%SDVY+]S3K>MVA&.E8'37M%;#XC56+T=4T@EHF[4?@>M+\3S ML(B`XB9.=Q18IMMSY@AG^Z;;"[`8XZ[C;2>/ MGVK;H7F+T^S08OPLLQ4VYEL+W#NO0M/=.SOPK_]&1[-<\Z0F3^"R3=(D/AHP?!)'[RSY4D]DC)(T%G-NB!M(:Q&*FLH_0SY M0HVMZ"&`1W>D=),\:0=($=Y_PD<[TR,<"T/\B833W1!M/VA?".>]&?L3(0H# M#6;!'5Z;KEYKH5E>Z$:!L[4_()X4'S#/C6^%\UQXDZ(2'G:6'D,9[&0S>N.Y@J];H$+ MDT;9JEAQU/YMX5+D";3BCA9RN_':%'C,%:`FL$K-9WS:*%G M&O>*6)O0Y,2:U/L>,L]53DICZ1_%L5)>OW+0ZP[EDA&[2=+97*RHVY]#L%L1 M_>>(?HPTBO:(HZ1<@MX*T6\-%:BT8U:C--96S8IC]^=U>QX%]F.N49*.EF'W M5$Z_QXH>N4$L8[UYPR6`+WCTMP<.;9PD`)'%8;R.?G8<9H;@KDB%>QQP/V'#7/ M=$<89K&Y-)SC+W$!"X<<@H0#O'Q\RS$?P,]!;).')Z5 MA:QZ?TH+^+])01%8B[`GL]D1M6"5TP[6F0-RN[AX8NE2H>>IXN#2J4+/.FX2 MGC`4>M9P4]5`5G%&:;S0\P`W!;\=^2:A/MIBSS>1KVR34!0;;*( M#?Z0H%QU/&F"T^X`?M*D'ENL@>[OB!#Z[N!UPD(3JZ0+?;>1(*W\2NB+Y<,< M3YBPTRMV>)^];E]N4J+@."\_QO&LR5O+\&/L/4*=QK[0I+!"7SROLR\?:U'^ M2SUHK(-3QJ=`7;NVU8A'ICN"TROJ.'U2-SD3J???R:T3&T%C8)HJ\8AUNI1L MJ]98X03ZJ:0.KM6B>-13HXSXK1AIWA.*NN:2_%:(_]AT3-V"!->5_^IJ7*#' M:U$.B9?F.TTQSL@9"KMPL2-HOCTX.ZF7O^HTS<`+(^?7:.(7*M>TL\PUF>K! M5'\=U!/\)]7["8.[6ISSZ1KJ#OBT;2;G1[-8%*(]0>32/[$>KX'4R..A$N)7 MCBG.7+KB',>(C4HG)(=UUQHZ#E(U*A,3FJP@N1HIQ?SDL2#`!CU,(U3'6^RC MTY*SV(UM-33>'$D+7$[2V MAPI)<&HT3>F&[S3(JDQ8("3%\?0"!YV2Q+'V_0/[[5.4`(`J.\@=/^"+)O>7 M^!4S*]9"$PUF&U609R#/2WQ6.-+^1@B"]F2\>FK.?& M*(M3GE&Z4PJ*LTIU<)SK/F6.PVKR[H^&>F/%M_#VX,)LREIC!0-OSW_BQ^/%RXTO M;"9U-U;\'=Z>ES$ZISC>^`+>_@T5'V]\X34,_<;X_'J",A-S_QOFR3=6-&*> M1S!/%G2VD)1YW-V>7/S,5*YYLTRAG-G?3K$;=+[8*1^""[,Q;F[>VP.'I M;K%'R82_G?*+`W[(MFI@78(CRT0F=S!396KT\?-$&8X0/PT[.5!(X/1Y*K!X M.K!1158M'I"_@O,BG@$\K9=E>B\:QCR5AF(O'&:6[X&DL]AKW M6?J5\R-250)ME;<(BP1NJA2$@V:0%<>O!=V5=:JAQFRK5N[>BME;54:#W(OP37=0:=Y[J'5*T!'8^.DE:QLQ/9-AEA_A"<(!\PL$\V- MJ;S`C:K)&A:70:S4M@<7F"LK,;+I[KE4I2%+W"@V`R3 MQ+&`00!S)HL)4G'T3J&?*L7X5CZQ5[U4H[7P1=! M6.5<%B#*-?.8^Y5`\DV*WPA0*#['6)FG%M^%(I.%@Y-*-T=&?\T\FK*CFL"N M16Y<2W0R-_"22R:]*5"^K5 M"F*5XY&0!"^J@B+'AA#AATN.-(-]0\A[&F.%'9NU@:6,%=A7I4)&RF6EM%#9 MSI+[LZ">N088PL0:>ZY!69FZUPUNW&MOK"*Z""OG"L)AC:Z.U8KL;; M2?Q6$N]Y^R.?[YV76*)HR5"%=S,WPT@2^,4=72?M]Y@5IH8QQ^YY#"^71/=G MTLE-JA;>ZE MXDGHUZ,J6\N":JAX2PT59UGIKO1N#G%,J&CE].F+[1$6Y1)$!"Y&>*6WK`O3 M5-9M-E1Z.38+(Q?P5^'[4\?]%;`\FFY/A(A.4!]_68!`Y=H2\7LRKN*@F2#T MQX+MV7\''RILZHCC@S`VVS'.;HHBAA_TP8J_@M"NO@IC7!'>7XTEI4B;6#&S MW;ZHPYGYMQQ8&\F5[EI*W,@@%I'@3DOP*FS2P":-?88ER_%4W-\J+O`=GAI4 MMYD1]LRK*?.,E;"1CSJA.7[Z1%$#_J#$HH;WR8(]`PU[Z$1FP_'VXW7'+ZO` M'(#FRK6`7O[J'9^OM4B6>-DVT+^12>HLT]5D7LU48H]?_*ZHX53;6^MTSL6T MN`A3)+@^SQ(S#?;?78WI5((2O!]GB;S!ONBJL.EJ)C]=;)86&;J:DPYLTCLS M-$D'RDQ0[]TSLF6E_Q>$HF_H2"H=*U.0`,!R5@D]9I@%DB_D9` M.B,M:18SOQNL?!,W&=%S$5*1H;*5&YTO97Z7`TGRR*:_$T7-2##HTIE7V;9:=A=*EHN;!RK5R.FA& M3.8YJ2@43)(&:(7A%K(DYFC1@?/$0:N7,=HCHDY^]CB+2#(EQ/6A<)<1P-*A<,7R[(UCMZ$V-_:N;7Z4(=HQQ(:`4/ MK7K+LW!]-7ADKV="D=S``'V\[4=2FS-N. M83&S;?N'Y'U.N;>\;P\0?9,QH55N_Q1X4=0F%IU3)OOE[!S(65N>/(E!.6M# M?(S`_R#8-AV@.%9:<@"9I3F1V>9BR*W9\E[>-.CZ!8;840ZI2>NC4#0 M:?5R\GOH_0+]VW+CSL8PO+-QU.1MQ^U5L%%NVL$I4F;7-P%XZ1E^*1D[R>JN^<]XDR(4%:5^FP:_C3OG#UW`LAHG\^'= MZ`?+9L1)&+!531##I%P#D/4+,7S-1/6FM`27C`K8_J9M;\O+N'XTG7K-SQ+J7.M M&3#7.B4>C6\"3P-M-YG!86$&`\6@'PV3(',:5*D-)B!V M75:%B_?B"#-#G52)C>CR"JIT;=)U-8/.2)?_C-Z/`X7_;$VP(GGB"7\]`NP/ MF1GB-GK*/(-4)$QZR#PCSO&'E[$RHV^J"+E<;5;13U?D;7]%;-V_WLC:NI\M MT]KD:/?@/+,&)FKB"7G/QS[?>P)WQPZ-V`D^T*%[W1J;K(WJ)8C5XC$8XPUX MGWN#/!V2*_%XTVJGZ!GZ"8$:&/VJ!R]][U".)\EMH;!*2A>Q^`$@]F$MQ?--4?@]47PUDWK@-5VZ^R.,CX?7&+@5$1#5@?*&-J2T`I33+Q` MT@HE![8DM.('$]@"?W7"66.\#S;XX-U/+;!*'KX^D/RH2_A&[+JAQ-14KX-E MEZ^`S/F*@J)J5E6OL#*Z"/S=IJ0#7+A8'U.=1Y#P[%)R@^0)V)&>R8HM9,@$H[)% MKM#AY:#0Z:M#J1SU9P186,*=<6*N.?J[278H!@KE0[>_AO6%N.U_P@9,4L$O M^<%CMK\]"/ZK&C#OW!&(EWAMFBS6=[64]Q)]%D]RW?L)0,I_Q"VLR@2QOKR' MP$P$%H(PY[_@_;$G'C9')[3")I*.5+P1GS,SQGT122T;@T\PYN_F:V):3D3B MS;;!5ELBS9VSN8*44U!<($$#QIZ>!`QF1(-!(#`VLT"EL?]'+V;!<"#?#TP(4 M!@+[MQ6RE5YCQ1TT\NN[(A899G2L-@I7A5H]L9U7&V$MTP"L9?/D0[@??_0) M-%(UY+>NSFABJFW5`7N#AGZG9T!*`-GU(ES*C!1'V[JS>`U]I++5N!7OX[+U MA6X.().T>)<]4W:B2:&V(D=^B1D2&CXXZT>,2^&A)]DY,_F$JBY;_C MX(V_(9,E\9$T;1O(XG3")IGB-+3;UD=OTA-37@FZ49:*`5L!<@48;(1&FW42 M;3>3-S]*U$N;(D7:YH/VQ!P96T6HYSB4O:%.WD7;(`S5GFT-GU*92ZEXQ<$ZBQSZ-MM9H4BC^W2NQVKFY? MI0IS)$7!/IW$RUK:XO-Y,;@8VP%;^4VEAJK>\,9FP1-^I%O1'.F= MLH29DDEU-74UB-=N6\+F`3!YL2T.`(O(+E#:(E]-;B+/\=&]^#8;Z2K8.)FE?"<>V(1<-1Q7@#:P*/ M(]V+`RS,0,9+ MBQEI@T'2E?^@M5#4.QAMM1W6*@O(T*Y$>],,6GZ<.I0O^*-?R'+WX=Q+F09C M=GG/=]#5BIMW3H68?8A#GHK)JDC"&<[Y[)X)@[\K,OXU`&PPD'%:7,R(]Y*` M3CR@&,C8+GL^P(LZAR[I$]V[,86$%X!/D^8S25^!;[!:N>188!#JM/9L@Q0! MOA9B*Y"*BZ&8,4^-`;4R&FS@,?(>K`Z)4KY?KEZ?CEAAE&,';P&5"AB86,&R MI.)1IX_-:"A2ZOV@\O,46:YKEO''CL2&%6Z8)=JZDS9K;:[;R>(@-/:8?"_D MP!\:H\#@.E1#Y-"V&YL(0FLQQESP9LGWG M@8$U]$1$P1N@DZEEN3*Z8BS.E%HI2,IC8EQQR7!"("[Y0:989ZME82ILN\0. MQ97HX&N^Q<@X4\0Z`7%'D5\I'3V:IHVQ'H M=XLHL8A927[R"1>:U8)`77Q+GT`'=D[!OM#;X8QS4Z"+UP>"=R]'B>CJ^A?X M/T=L^.0Q[Q7[F<^H;X+^@'^L`?'QUO+J^'C;!<:>J2M_#J:RK@ M]+4`\JY_/1E]&]2YX(?&$02E\V6"X-UO(O!&S+>+%WZM#5`[9$AB&,"5B#!B8BJ`H1H/Q#Q_1:-`9 M?$0#0C2^$X4$G?^0:,SP^[OW5K/(8HQ_X!\[R>6S]J[;2'L>]YS?[UP94LD8 MR6MSUGPW2X,R5O)Z\GZY68HW M"G\P%/SQ0K<*R2=W,C,/_*+*XY&*H#-V0^E9[@33H>GOB4>D;XDU%^]C]-9. MMR+S,_:&_]R!LA10Y@R[4.(^5N%]R"RWECP-HL>U=,0]2&2K M(KQ/RUSX>DF@E&$FRE[_??@0;D(97&]&B4UDE4K+G3>WXN.X#;$1 M_;+ M4:ZL9N"E>#G*C0.OP%EX%5Z-U^"U>!W*2E@8(S@7YR$K/WH^WH@->!-&<1$V M80Q;,(Y+\!:\%6_#V_%.7(IWH72(%B:Q`U.X'-.801M78`X=+.`]V(7WXBJ\ M'Q\PW,JOUV`W]B`]N5YKR`J)TNMEP0XWX$;LPX=Q$SZ"FY$%5OT8;L&MR/6J MWH;]^`0^A3MP)^["9W$W/H][#'EC_:)&&'N8ZG]8:EL\RPUC0EEI(!`H(.36O63$L\6_Y^]EC'^<_#6E)STS6DY5 M2%_CL=E(:\U3M.=5G-"&'J1N^HW_+743GLNQ;YF09.*+[8+?[C5,BN MZG[S_>KRD/1<^K-CI1C)LSEULKZ\6J.W9E-6X[59DYK,Y.Y M1*>5KW8O8:Y/VPDGE6FOS=JIC&/F"]FLG7/,C.V8G&FSVBK&J^9PRX+&:'BA M.;=6FHYM)M)I>UG"L2=76.84 MUZ_<=UX[&'$O@%7/9X^&_?JY[NU0 ML=[7A)0YLTD^'K^'I1(?BTE3&E\B_PYM=X>'$?GZ[OX_`%!+`P04````"`#6 M>Z4>V9\BGIH`````!```"````%-(25`N5D%2E9+-$H4@"$99L''&X?E?]\(G M)292E\E%G<-?17\%\PONI<"]Y(:K#L!'P9I_XKF@N#76*^?`Q@^"SNX\%4;Z MX)F@LTW>-CZJ6V)>X%YM1K[Z=QX$YIYP?L&\?M:S$)NCW,H]W641FLY,-Z), MP.W8LR%AH*AY2`!```$`P``!P`````` M```!`"`````K$0``1D5!4TTN2%!+`0(4`!0````(`')RM1X`TIR$[````)`! M```*``````````$`(````'`2``!53DE615)312Y(4$L!`A0`%`````@`;7NE M'FG0W9S8````5`$```0``````````0`@````A!,``$9%+DA02P$"%``4```` M"`!/GY0>%):@83,!``!B`P``#``````````!`"````!^%```159)3%5424\N M34LQ4$L!`A0`%`````@`7;FD'FPL7Z]`````7@````L``````````0`@```` MVQ4``$5624Q55$E/+DU+4$L!`A0`%`````@`?%6U'BT)ZLKZ$@``C$H```D` M`````````0`@````1!8``$9%3TQ$+D-04%!+`0(4`!0````(`/`*MAZYB"P! MS`0``'\*```(``````````$`(````&4I``!-04E.+D-04%!+`0(4`!0````( M`$0+MAYO@1AC:A,``*M%```*``````````$`(````%!@``AC$```D````````````@````,74``$9%05--+D]"2E!+ M`0(4`!0````(`$T+MAY4@=$OM8```"CZ```,````````````(````#9\``!% M5DE,551)3RY%6$502P$"%``4````"`#6>Z4>V9\BGIH`````!```"``````` J`````"`````5_0``4TA)4"Y605)02P4&``````\`#P`]`P``U?T````` ` end sum -r/size 11938/31808 section (from first encoded line to "end") sum -r/size 38163/65832 entire input file - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Mon May 22 12:07:22 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDcox-000fJIC; Mon, 22 May 95 12:07 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57074-1>; Mon, 22 May 1995 15:05:39 -0400 Date: Mon, 22 May 1995 15:05:30 -0400 From: Jeff Lait To: Directors Subject: Collision Detection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Okay, a while back there was discussion re: collision detection. The main trouble with even simplified box detection is that the sprites change shape depending on their angle (This makes sense: a unit square rotated 45 degrees is then about 40% larger on each axis) Furthermore, a pixel level detection routine is damn annoying because we'd have to rotate the maps before doing the check (recall: at least in PCX none of the pics are prerotated!) What I propose is to equip the ships with shields. Perfectly circular shields :> When a shield is hit, it glows and then fades away again. Colour of the glow could very well depend on the strength. This way all collision detection just needs to be done against a circle of R = W/sqrt(2), where W=H=width=height. We can approximate this with an bounding box, and just do specific tests if within a box of sqrt(2)*W dimmensions centred at the ship. By noting that two circles touch iff the centre of one is inside a circle centred at the other circle and of dimmensions R1 + R2, ship to ship collision is also a breeze. So what do you say? This would be easy to implement in FE-PCX, and I am sure on the other platforms, and save a lot of the collision detection woes which I saw being discussed earlier. - Jeff Lait (SOL) From phil.ruu.nl!faassen Mon May 22 13:44:33 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDeL0-000fJ9C; Mon, 22 May 95 13:44 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id WAA18362 for ; Mon, 22 May 1995 22:42:52 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id WAA13138 for ag-directors@alnilam.krl.caltech.edu; Mon, 22 May 1995 22:42:47 +0200 From: Martijn Faassen Message-Id: <199505222042.WAA13138@laurel.stud.phil.ruu.nl> Subject: Universe > FE interface To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 22 May 1995 22:42:45 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2393 Hi there, I was looking through/working on Universe code and a question came up. Currently as I see it two possible basic schemes for the Universe/FE interface are possible: FE-driven: FE goes through the object lists of the subsectors to display. If objects are tagged for special animations (explosions, birth, and so on), FE will display them. FE might want to keep FE specific variables for this in a special section of the generic object structure (which is shared by FE, Alife, and Universe, all accessing different but overlapping sections of it). Of course FE will also display 'normal' animations, like ships moving, turning, and so on. (picking things up, dropping, eating, and so on) FE knows about the special animations by special counters or flags set in the objects. ('this object has died and we're playing the death animation, frame 1' 'this object is eating object 2, play blahblah animation, frame 7') Universe-driven: Universe has a special 'display cycle' in which it cycles through all objects to be displayed after the usual stuff like movement updates, collision detection and so on are done. In the normal cycles animation counters are set in the objects (possibly only in objects of subsectors that are displayed and around the display area..this would work for the FE driven scheme too) after the usual stuff like movement updates, collision detection and so on are done. In the normal cycles animation counters are set in the object. The display cycle calls all appropriate FE routines for display. The FE-driven scheme has the advantage that Universe doesn't have to care so much about display oriented stuff, FE handles that mostly by itself. The Universe-driven scheme has the advantage that we keep as much FE independent code in Universe as possible. Possibly the arrival of a generic FE group (so not architecture specific) consisting of people in both Universe and the FE groups would alleviate this problem. They could simply take care of the display engine, seperate from Universe *and* the machine specific FE groups. Then again, it might be more difficult for intergroup communication. Another option is of course what I'm doing now; going through the directors group. So, does anybody in the universe and/or FE groups have any comments on this? Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From undergrad.math.uwaterloo.ca!jmlait Mon May 22 13:52:23 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDeSL-000fJ9C; Mon, 22 May 95 13:52 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57124-1>; Mon, 22 May 1995 16:50:21 -0400 Date: Mon, 22 May 1995 16:49:27 -0400 From: Jeff Lait To: FE-PCX , Directors Subject: POC III, Fix... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ahh... This is embarrassing. I dropped out of OS/2 to see what sort of FPS I'd get in pure DOS and guess what - it froze the keyboard! I wasn't properly reseting the PIC - the old code worked on my old DX33 I believe, but not on my Award mb. Oh well, patched it up and here are the fixed files. Can someone remind me where the FTP site was again? I keep seeming to lose it... I'm pretty sure I have it in my mailbox here somewhere, but it is due for a cleaning :> Well, without further ado, here it is: (BTW: 210 FPS under DOS!) section 1 of uuencode 5.20 of file update.zip by R.E.M. begin 644 update.zip M4$L#!!0````(`-89&-K`I(#`)&$R,:HR6QC:451!8I\0%WLX!4UZU"I%$PZVXTL8U+ MB1&XQF)-J+&Q08VM*29M^C#!..D`F\&J97P:'3)TVHE9R0:KK6(UM4VVW[.0 M,MF4:[TF@28E6M*K+VO-1H M$<-<<[,=V9I\:=\9+2H:-9.J%$NQ'"K_"BHH91&(TQ.!PM>!?&H14YPS\:$Y#K"V[<3[Z"'/W)F(*I M.![OQ8EX'T["!S`=I^"#.`VGXPS,P(=Q)GX='\59F(G?PMF8A7,P!W/1AO,P M'POP,5R`"[$0%Z,#'\NP)58CD]@!7X?5^,:K,*UZ,%U MZ,.G<0,^@QOQ!_@<;L)J_!$^CYMQ"]9B/>KX(F[#!MR.._`E;,2?XBNX"U_% MW?@:-N%>W(?[\1=X`)EVHAD/XEOX:WP;?XN_QS_@.]B"[^)A?`__B*W8A@%\ M'SOP"![%8_AG[,03>!)/XQD\B^>P"S_`;OP+_A7_AA_B>0SB!?P80]B+%_$2 M7L9_XA7LPVMX'6_@O_$F_A<_PS`*)JI)$7X5AV$4FC$&8]&"(S`.1^(HC,<$ M'(-).!;OP7&8@CS+_O$X`2?B_3@))V,Z3L4'\2&KQ%+EV=,\JW=F]K/714/M;WU]T=K7>U*)'W M2TJ+G474ML2PY'2.+]\ZS!H9@\5.1.MRN1$9K8?2Y+1L;HEA^7KWN%S:1J1V MCD\M*74M"RSB3J-2]`1YPK9Q\N1(&=W1W%MQX!^[9XB@TV$*[J+%.)1@"FTZ M;28MD_8LC>\[N(7V-NT=AW*^J4\/MBUM%1Y M/R<*B_1/:]K54[U3;I[JU0.G0E,R-R=&/F61?JROV55]1/X2*/!=<94$G$7Z M5?U3/4H_Z>]5QI[V7U;&7F]KM]YV,&%,;'M=M&[3!BTJTJC*TW2;>?`RLRPS MZS;+X&4666;1;=;!RZRRS*K;X@D,[O=U-'ZNF M[68C1&,*&ND-Z?2>E+_4O18C1&,*&ND-[?0^D(]ZL1&B,06-](9X>I_(1STS MW@C1F()&>D,[O6#3!=64EF2$:$Q!([TAG-X1^9PKR4:(QA0TTAO"Z9V3?[J? M3S5"-*:@D=[03N^F_"];QP0C1&,*&ND-Z?2V-^6IICV$!Y:)+=)[E?[YOFNE0ST'=/[:CK,D0V;H8OCM/DL5,+[>*-^\)A5=39S&VA$36MUCJ;I:;#FN\+#(SW.!?K8]`4O5)C MW$].,:[NU/2HMEYK6\BJ:B_+O8P=6K3@Z[AQ,>[U=JN:^$QR=;N\:&C6G<:O MOBG[/,G5O9&:Q#O5U"7*X2Y%AG-J_>.E*:'>LU\Q7MK`>-1TW*FF3MXR]WW; M7>M.2VU\M/RX<9L?"(?#2_L_LXPW?.;6Q\_13H5T+;)G4VU5539P4E"NYPS? MJ8?TG"A^NJLF8-4+KA4Y[85JAKK1K!=8=+N6T?W$1Z/K,U/4DZ/_-3SL-=7. MKO\\+]]WJ:1TF8L3^K_1?-_1R&6GLC'MP@Z'G9QC.8EOD]AG.9-D4ZD41$(B8HK@`I`ES:\_ M=`-\2;)G=DNINENG')-X-AK][N;QLUW\/'QP#*_/3D;OV_;7OK2N$Z$ADIEA M(M-@$@ZV`R;S+#)"VA;%_S$7BL?V[@$P*F MNP,+81):1MNG*+$#=,XC,1%V"9%1SXS=\(F=BROM[%!`,.4K)::)@?#H:!\A M_F\^F<`[)DR[&'/)U4QH;<\&4\4R8\$R$F9\-N9*@YPX%+QX)R8<#&MW.LMOIM`'.#8R9%A%+TQ7$TB+VQ@Q0TD4MX0)>V0>/!?J]7N'?9S?-PAHQ5<--C=JOG/C[ M4+'%Z!]SIOCWUC'$7)L`"(\I@9MK;`>WG+1X8I72*'YN-#-I]I[*&7 M9_BX93[>9W.^YCQV>]H%_.9NXL,'WX-C['^\ M6QXX^Y^/)]=GH]TM.;J\.K\^^P1_M1=3O+WU;[^=7UUC3^B?L?VHZ._9T MNGN[/2#B;'?K%:P(PR&\?/A@Z5C4OZT:;Q=I_#>^NIA,&N\C/H7A)WR_8EDL M9]@9=GM[^_V#P\3)NMV=_?T\-2)/1<10S($#KPWPEJ\"5"R*PVRN#8PY,/N? M,:AXV`JE_I1G7#'#G385&W;$"SC)5J#GTRG7)$-?OGRY.]"'0P3]&C$]0,ZY M+#19$TA2700>*:7SJTOXK_=[80!_Z01AT`UZP5ZP'_2#@^`P.`I"VQ@&83<( M>T&X%X3[0=@/PH,@/`S"HZ#;";IV3C?H]H+N7M#=#[K]H'L0=`^#[E'0ZP2] M\->'#UI^CR[M`78K^]0+8"^`_0#Z`1P$<(CC6O9>B=R?>89X]@1!>W8$SVG^ M4SOF[,/P_<,'[O^"^WD6Z]T2P>G%\&R7ROC[]=GGZ_ND%&[X&%'`M)[/.$1Z M0',"B.T3GC(`[I]V3.\GIU<7.Y1ENX3M^NKDP^C[^XO?\#):0S($G=:R*.2D M=F\Y3)2<>/1BO#-<[-*HJ/IX]98+UB.0W#EUTP;K@(8SPV9J`N-8W7[3G#^_-;51K8+[6/J M^HIXP<-+Y?#A^A$5KLMCH^#B'5JG'S^<7I]??/@_2L].?0UYBK;+,>"=:S@[ M^8RWSD`YY19C-[D+Y"QYI2)1@&M0(L]Y[$C^U>GSYZA7=@=A#3YTA")[:?E< M)WA_P"/[.R[NT;X%$.ZS/=[;3^JD[Y;`EGF*HY!^$A67=.`(IR6RR',$S1P[ M!D%JO9:Y'>*10>3\3RWE]B_9C<:/&^-+4-UI*T8:D*UNUT8\*7R,I\?8C3^`A$-4\FHX@/?LACMO%OV"5+#, M[%#PK3D]!6T@4&$G*5"V/NIGH0T=A+M1AKU/G.NS+'R@TBMTKX5!6B*3<&G_ MG@WI_U>?=XTZ\E$+M"$!+@N(*LHM@:RD90&HI]5C&+%;3M&T6BB=X2A-Y>YRCQ8'3#A%CUF&Y' MIC&YKO97XF'+>RB=G*!:JW2$&F*JW"D6582CN%S6Q`=B&?W'EN(Y:"-U[$`Y M33E3"(3%QSR'(DA2G:"[[TY06B[^KNR4HP('L7:4@U#1+3>/B[8,4JE#7;LV ML$1M)A=(+C3,B.B&*_@%%*>-#`58>>RD?^.F$.]:-"6.8ZZ?)J1]P.@>(>U' M/"%YLJ/MUZ)5377,EG65#!B)U/4;*ZG'-\8ZJ*ALVUTWK\]?@VU+6!:GO':# MN%=-6WJ"JXO_$N+R0N#C-%TY\W,AU0UR$O&]]^EW>67GGJQ+R/4`X-*"9U8H M0";`;T7,=ZH;D2WNO1U']F\L1C%F53B!A1AC)(0'=4$8%]+2S=(HWE%LP2^4 MU%`R'="5`4L#Z*/^/8;AV:N/;QJBL3/NV)_$&TBOOER?P>7U%7RUG85?TFA\ MWOUFMTTIOO5AZ!:\0V^D.)#X'-51"1]2R3)*I@072YS]C\^'G:20"C=\-99, MQ<"BFTPN4HPA.C9'*$GQR;G%U++8XJ0:AY-SQ;5^9$<9]/+&?G%[\1J$`<53 MSC1_:?M_9+_#W[F2IPE3+#)VNP)CLW,6'Q$)*D1&-!:*`]>8Q`MG[, M8;7:W M1Q"P$H)F'Q&<[>OBA="-V,'D8(@(SB[.T0^Y/#]M^XEVF)]8,/\&YPO%C5ILQ)"R=8)(FD7,%8SZ1BL,Y9-*("--3Z-E@EHFX!R6%6^/#JP&\ ME0NR:%9R3GKS$S,1N45C#)PIA%$CW0GS&(6>EUF%0D/=(6EN+#'!DDKM+*:; M8W-IE&&0C3],4?T0? MHFZI.%(A7D#&[CG'S+MD/MC@!L;+];ZFMP:NDZU/_&J;GNW!\\)6J<5"OVW8 M1]#"]()Y)V7>[87$MM[+%4A)'ZJ["@'5V5)T10T2^B<_F06C$;P$GMB M'GG!20*IOF]AV:!%$ZTIT3IN?Y9=LY;P@A<0W46[M6$-`G;/+M95(^!6J_2F M?/H7HYQD\K4!<,'U,)ZFM=N8[4;;$$/K,RPQJQ.?" M[F&OX^+N>P$9)' M@&O[E6Q01.^)'A.8J\2MT3V<,?1N)>1&S1E?;J(Z\@DZGU:K3V(S%O+`34#*2".ON#QI" M\K!3R$C;Y&1D225>!I(X9*4X],O4?;QMY%$_V\^,*5'2^02RU<.=(OSMNE2ATL+J$4^<[U=956_R,"B1H1^]K] ME==YN#786FFWHRZ1!G)8,^;=GTA&W!;40_D#N_^W MP&4V6L?P^5_:YNV?VN;Y7K'1,7RY:Q_*>5#HK#>Q/TEC@<-O951[A#>,G97] MLE=R""M"T]74L%O-/96IG),/7MV`&T[\%&TQ+XZZ?\14-7+X63Q5%H(\:1:1 M_*L\56>H.E?A'O!:JADSOLKL+64]D!EIO=Z`&<*JDU5KUIT*4(-XF2BTS[2C4&43$(UXENJ"HH MYHQ.2O6.;&*X6MB[V;THJBJ$[A)%P,?Y??JJF8>J"2MD<9(1)![BSV5['A1, M31U?UL49.O;(.M=DW&;_?8/RO M=LQ=KHM=ZL*UR@G=-SK86T((L7ANU\(P0AG@+48_.7ES_N@I68WP,8^13(B0 M(CI`7.2*QVT0$RR6?1RW-\[Y_/!;(=:H4U"2;NS$;2`ILTN@&49+00&YOUPFSU^EN$F)A6KS]_XY[>[I-0MQR.D^(O3#< M),1_'V2$88,0"]/0$=\GJJC+[#22K,R4!>Z%D&UJB&VZ9$<*8W-I>[+[%`85 M^V"*561")X--&[.F$P?WFIS]?EE,<8_965/]/RVP5:^.WO#SJ\!6?=B:A;I9 M0=VT3EW-@+-.6\XRI09OD*(%Z4G`?4@0MP$^CJ@Z362W\H:C>BU!I-Q.1#GW M&#]4<.DB5THZRI&X3C&[`K2NKQY%XY-'##]2D!/\U$.J%6:'-)JKF='N$XD8 MVN8J+G-SPR,^@+X>ZBG M&G0'[:R5R->#^[[.Q!>:@*]KU`(+=^BC(O-BQG*,5(&A>*JSS>"FOI<[AEJCP?>6^X M\XNP6]T74?:)PC2,*X&D>0(_M]+3.9+`%,5JQB<3$0G,YI,96(M^=!I)'4=D M+G59A36UD8X51B_>XQ\M9]PDR&X\U;P9;2F2YE6(F]!U^*T1`'4H[*XK84>, MF*/.A!$6A1/,%U-.SIFO:RGVUH]H^3N<97'/A8BJ/7K4-&I] MN-8V1(7OG5.#!1H7&SMC[&S3KW6#4N5,-%2E(?]L973 M$'>%GL*O%("*^NGYX8/_^%]02P,$%`````@`V".V'AM367"_@```*/H```P` M``!%5DE,551)3RY%6$7LO0M<5,?9/SYSSMD+L!>,>(WB:I%H4`O1)AK0H+"+ M5J-XPSM&(T13;X5=-*F7)1M3A@/4MFEKF[1OK*8UB4E-0M)54[,P%O!R&L#4 MX"4I4=_TX!)#A"`B87_/S("7U.;]O>_G]_O\+Q_PPW[G\CS////,S#//S#FL MCR[^&>Z#C/#O.10*_5I"9H3Z2@@EH__Z9]=(A)Y3$%H$O]^#7UU&*`=^/Y-N MT9P,?KT3?M#<.1D)K<%!_@1TN%96GR_'>B'R3JJ5D=O@KY6#<;X*R=>I;/D' M$/7S)]TDRA)$GG-=]9=`0.;B)73N?/*?^8T%*/]S+R*G])="Q+59-1'7T\6N MMN*,S;H1$]<6U;6YTK4-]!J)_2ZDC\90H-^']2F84-6DIV!](/9CU#`/S\Y8 M``+3207YB&1VZD,9@9TT)=3J)^4=`8]3S>ST)BUUC_4FC7&/\29]USW2FX3< M1N\6_+`[6G5U'DI'^E]E2.@/*D"+J7=[:*E;J3`M32%UY*H^06E8ATB;OE$A ME3L"[J7>BYP[$CZ_ZPZ'SX>%I`H3 MXL*>4J`A4"V!J1:FNQ&AQ!ZT,5ER6G`OB&64C5&)L MA5[%%BKQEX[DHZ!Y:FQAE*N@7PK(:"%5P&'*7+P(#*M&1TOZ-&4)G7,H7M(? M,DP,A=R1_G#$'RD(V7#QJ=RUCRQVNU8^92C2^JT]>ZLG/4KW&LVK%^Q%BAR-HYQ M)$P8/WYTPH0)8\@K+'-ZQ',KIQ M,$,J*3L7+SWOL#KQY`K\XJC=>&QOZ^#<<6Q%['Z@=)[UM*M?QI('!S+)@R2AC7J>M7JVI)R, M420"31^,5]ZOE>,^.(":7_5-,DK(T]]?K.PQ2D4VL[0G',`B[;$!1$IC/_<7 M*7ON@724I/=2]-?E="ZLHW@20B7E!R.1'^/F/RUTQZMU_E?`.N\=4.:FSSD$ ME6GZQ_+"TAG:T'0_"*Q; M2$^VQBJ>.Z'H8>+>2(G MM%1/0*1\RHYSGOZD6E]N(!366(1^LH-Q&E#P*(C]Y<80K.43^O,&6*B9T.SL M!4926517$C@8"B4$KKYQK68:J3(M7T0S%I!*3]Q2@6'A\DSN`+AO4Q^,EG:TNA\`]S-& MWQDBE<&A:D8GJ2(W]/$&4#"2G,`WO(],])B*G1A7!2/`XZJ6'<<\9Q("W)DP M[P!^TLC5N4W36:]#VY&O@1X6EC)"RM.X[]7EI,W$/)!PK?F-NX2OKB`9F\D9 M_0,#B"D'W^*)T]^^0:CO$>P9RESL(.98^W''VLO_2ZQ/"G'SF4E;P^]1PV\1 M:=)/=2:#H_?O1'&NIXEKF_<1Y/Z,U!U*1/J38L)(G?Y&)_D'KB1M(^M@ M(TAT;2LFKE%7Q)6G*G+F5ON=-UJYM/Z MY#`@4D'O$WH_@]"ZC_YUN]`Z`MRWQUB\##=X0J2Z^`]>U.5X8>`JR"G?=@5Y M##`/[@U+"+6FF11WA/<)TXWW,?+.,DD)QY@_=L&86,A9?3ABHC\G93M"[MY` M]360*#`")NC/A#!21JJ69XH9N@`RIUK3C)*GM^YN)Q65BL)ZXYUE=#0\@6ZV M^4?S$:3XKH=[1A]!1B!/]L2`R$CUD0J#-60*I4EJFI28%NZQ00-U9M#"P$QR MGZ`I$"0[-AD]YBXZ9M@#0.>I*ZB*O\25F:/VO5_9/4JI-*Z7D4//;FLPMD?/ MU=4.]1\9A>6)UW)[>Y-@F85J-AG43PI3L:_"&&S(3/R'VP$RH[U@P/"(-,4M MAY9+05-$`!(+I"$5)BGX_I(A='PJI@LRYLP^\H;\_DGYX$3S6R%]=VC1XLSE M].'NJI,R>)J#"\UO(?TY4:6?")W0+X1.(`H3C\U_7Z-4G-FZNZ\$F^8&F((N M-;.5-,5%]Y5JZE,,$L)U^D$,5@^X)^`ZM6]?:4\3)E7Z]TUJ=!/>/5`B)F!7 M^[)"7[FDCT*D>7<3KKF(818A1!Z\@H-&8-ES!4,Q>7"4LN=^I3B[C:V895WS MW]=HAMF0V5;IZD#(F^1P&[Q)81[9%6QF\SW1FS3,D^@B>>T$\L-8B(%8B+'4 M8X65,(P'&DL]V%6]GLH>#;+># ML9L8^[\R_AT8:Z",N#I55TWP!!0;"?FL?" MB8;OAT2IVP@%#4DA-;,-6,E#77'&CEJ/G!!@$$GGZI]>(Q1F4J4I#"WA'HC0 M^$L%Y:1,/W$-S&#)OX%P[@/>26U8SAG@O9'N4=ZR!2.]-X;E*&_U#IJ\-QPY MTEL&;WOO/.FMW@6GXD.%/TZ6=P65@K;X2Z1"?P;$DX>@`1&QS)YCY!:6^!`F M5K@ZT>&%H8WR]VU9`XT,%]?&71E)2 M%[2"EU3B`T'#=%=:\$BWH^[JB&\2Q$B>T8='\:@M(12KFA)J8;!*`@GG8IF_ MZU.\"?.$0IJ#S:1Y2E!OR($.C&SSR!#1ZI<[P4(5T,-,4EU3SZ9XM7ZZ$_+3 MR(T]T>!V$FI+7)U_%%II2"A37LP'/5S#+)P<_99$@/L6F..1W M1TNP050GU.YQ2'J&.6@`5[#6S`PF=H9T?U^LYY@7SA:=R&]L1>ESYC*77^P* M5S,*#D]'^A\[(7UH*=*WF0^-03`0,N3U=U@8.X[5O(CUWUY/"*3[D90.^73] M:;/OJ)%4,*_X(",8@_04,ZF,-AW9C5]^>>_MI+/,I)P3ZZN^(I65!HQ\[2'W M?:2I.&/QX4%(MX0S*0-A^[@0KD_^BKE,&>E)/!&!&BZB_&V+'UWL-@$L?M1C M`/\54U_X+COP1_*V57';5@8=<$XX MEW#L$&PL[X0;O*A7N\$.'X0TZ4\Y:NNR/1++1+>-J7,D-^5QQ9B'( M?$\M:'\C:&\IX,Y:T.Y6TK=A5RL]CTWK:=OJ,VU?6T M?L0(*X;O3WSJ^H>`#L0U&=J9@$P_IUPW=$R\=9EU":T(HX5@P#*0% M8HF=E+$EL2$$T^QSYG,DSST[CKEGD:I#^9*^+<1/9)/)S,[@0#A7J1EM^I,A MMG8\O8`?%@D[5G;ZF`.IA_BI/P2\P7ZQ2-$D4QJII,JB3 M:_'_`2*GJP="+/J%S@>3&6URQJWN[@\2YA.J'K;[M<+H<`D&2 MY#95IH4_AX+W\(B)9:`3!@`$(4NX'M%.TA08H3X0)+45IUE8G`0E@DR!*`@" M%H4`&UQ$B`T(8C$(OU)-D>Z'O:M,7[2F&B7W&-\6!;E'J$LE=9ZBIIKUI5;F M(^"('IR5F"JY9^H#OF2NQ(+>AZ@H*3B)TX_WKC("O\GA&0-A]Z_)J3#J[LV. M"H^4R:70[RU*4[=9%2WFQ,K(7C:%!474J,2R_,& MQK4SDNMR>_&"2-6M)%[U_)-L#X\+!*?'59/MYE":19VA^-J-.=%JI]Q&MAM) M'Z)`+\DRB3RJD.V*>H9LEX)]0K-L:H5Z775+9(M"/!*!QII\%JQ6P(8Q9!'L M20T*OJEC,]1=D51E'W;K,9U,\C5PLIXAB=N-'AE890-1YJK+)'4K:P+:6@+R M@UN@Y>U&"`-MB1YITWIU>U3BM9PG@G:@@D1F\?;(Q$WW;,J(JU5!ZUFVR=>^ MG)98ECM<76")JY$#B36;I+@`M)6D]FDMQS!BX-/-W@N=3!#!G"""/9)/FH44V"Z-?WA9$D)3Z8*6\* M3YSTF)RG$/C$URH-H1!I`K,MSX09ZYLT#V[&^JC13\JJ"=<9%)1H;,&@I@EV MI4#WE"[W3=H&=V.&A$##8>2;U(([W2U3P#H0SS7JAT(CRTFU(1)-J,[YA)0G M0GR>:U+[KI>9^?JV@)]IP;GRH4XXM.C5X82RS>==V(/:0IO^-*$\[S7@KO$U M*!-J-KT$82_7)TX%(.UR'_)1\8*.">V>@2KT$93#"CF-82.%+ISB\SO89Z(% MYD&TJ>`H.`D(M:Z*DR3XB#D\JM/7?LVC-=AABOINE&GBT=S><4>OU24:._`F MYF-XS%F>$^"AZG,QU"C5">.91GU(W(=]2\;,G-@[6O M45'S;!!VLV@>8N+(&!\$J:Z.0HB.KX:[[H'57SJ1NU(*\6GM=@D66F6K*U)V M9_C`Y+/A5O"/$(MZIK:Z>BGN?N1&Z21&K?^VD52P&%J!X/L+!`S)[N'%<&"_ MD7",W6YTR]L:VW/6QJ.(I#J60[T#O?GONN21R_.C,(GH`\LWO)[\5BC M5TXXML_KD0]B1*[&?UZ:=$O:EO>Z9%7RW!O=G;B]!UMV06V;;@N+22+ED&A@ M!T?9^S>'-[MCNV];A^21O<=E2""6P)#`+"&!2I%`=]Q+JBW)T%G9;89/R6T) MFO,G):%`[-R5W!?H;]@MB2##DUP5#YO;JUTN!-(LQ^E@FK' MX(HQHW/'L:T&_2?-P4&%8*=F[W%'?*L?WUZ]Y5-^EQ'QZ;+#KZ**@AC?1/@Q%O;N+C*CA=VA?LGNPFMFB9EPM?:3+**XVB"%J MMR[6>S1 M@;">7"WD%,22&,5EM@\XYJ/85X/T3!0<[GW$ZC:E%=J3"RRNE"EP2YSS-Y)W M=:2KM=7UM<-C]&UK19["+L/Q:U^(M:@83#[IX,P#I]^731!26?3)EV]V4NQ# M8AZ33V!DJ\E5 MG>PFCSCF&33=W3_%'9]X=E.86J66Q]5>:_[IM6;UK%H3=XPF'L\9Z(E,K-MD MB:-J7=RQN%KP(!3PW,]_7$/G9RR(:U4[U2ORN=['X<>W3RLYDS-N3AZ;\U7.5=D7F*I::@Y)]/>-;E?!#FJ=>IQV!@_6IZY#+P^ M#-WI0J7`!&&-XDH)MI"ZS)L6,[(S?3N9V0'G7D7M&RU5PMD3@?N-(J>"$?"( M841C,G9UIJ3X'D&>IA`+(RW(':$JNKT1MGRH4B>ME]G5223RN3KM[`'"=[^$ M>3B"I89_R0^OT?K/='%SJ!?SA!D1X()Q8-=AE*75;>UDL+AJ+JI[4R'_./4% MN8[+U&UF8H6#/1D,*H'3#EK4/G!LNQ^NU%+2TGP3D><+.-JG<*7,:A3X9'UG M,*'6!Z?\J&`X\.`I>G80E[M<*HNVKOC:M^4-UA6]ZQHM]$]QC:9FMD-7E[K4`TB5-8`T-=+@8#U2C0:%?)!+VK>&UT4**D[Y$6E`[6A0`6/C0[@TI': MT*206WH@4%CW_MH["]J&L#U5W::,/7:MY@&^KQ+;T[):TW66Y8>5W1+$N*-[ MHY+`GLWRV)!OFQG&_,C"@0=WH:#Q2-/`@R^CZ**JDKKFO4/>C\=JGJ*"B.:] MJJT5^\HB.;E#=87+9;%[=B+598G=\S,`&\L_#XG(V#V_1*%HFZ0&BP*'XC%T M_`)K]S""&L1]+"82'$8`@((+QUM1,G\YO$P/CX+)[==358!H\M]3$2J6(';PB: M&I>QNR5VGB6G2RCH-S,\NJ2N^]0TA)W@RR6T>XL,#LH;ZY3:C@R3O#:GI,## M4P7IP4;P"YNDW2/@$.2KL)'H$8IOBQ%Y+E8:8^$Y;28+MB"0:?TD MVN=UWWL`)"740E`#^PW?:.`2$;;QJF`PAFTPS>3Z[>'.EL\FM+G#=.]%=F]C M0?#X0FQXCMQKDV?<[%KNX.'+P\1^B9[3G;^,/_'.P,GZ MVW`=X0[;#7GJG84=:C307<"G5!-_NLVS]5#UMV323]SX&TD-7$52B/)Z2R;Q M'(#0HBJ8>D5U,.>*`L145`U3D&NB/ABKP*F^#WC7OK'L[*;+$7"$$HS0FS\5VU,"W&MR[=FMZ)$1BCH(CC[W)FZ7X);R MD^"7WD>-LOH(26*ZP;UQ=*S2==2!*>EN52&_&U0=HO=M877!?\Z=PR8CC!)_ M*&%/3`,YZI#@%9B3\*+!8MY_G<"3-MA`5#C%+*&&>#1Q`MHF&^Y#W&2W33=] M@7)88;37*A0W;@Y&DNH8>WS+FXI^+'3J'J=HNZP5R2%@G.8,@)#5$-4TVB M)W=23:&:@6I&JIFH9J9:&-7"J19!-0O5K%2S4U353;3+6GJ/8TU7Y$M2U4VTJU;53;3C4OU6!P MGZ&:CVK/4FT'U9ZCVH^I5D`U0K5"JJE4*Z):,=5*J/83JL$P_91J/Z/:SZGV M/-5^0;5?4NU75-M%M5]3[3=4>X%J+U+MMU3['=7^@VHO46TWU7Y/M3U4VTNU MEZGV!ZK]D6K[J/8*U5ZEVFM4VT^UUZGV!M7^1+4#5'N3:F]1[6VJE5+M':J] M2[4_4\U/M8-4.T2UPU1[CVI_H=H1JKU/M0#5RJA63C5*M:-4^RO5*JA62;4J MJAVCVG&JG:#:2:II5/L;U3Z@6C75:JA62[535/N0:G^GVFFJ?42U.JJ=H=I9 MJIVCVGFJ?4RU3ZCV#ZK54^U3JEV@VD6J7:+:?U+M,ZK]DVHZU1JH=IEJ0:HU M4NUSJEVAVA=4:Z+:EU2[2K5FJK50[2NJM5+M&M7:J':=:NU4NT&U#JI]3;5. MJH6H-CQ7_NUU^ENHCNU.P7;!ECZX>MCY)B$X=IV^=?4G#DO#?-LEY!X$FV&D M.QP>>_X:5_6Z"L$XI$:6#3@-F]A5YD`:[+`7@W=C3Q/T)Z_R/864ETX6NQ_? M%=^ZQ+>;)?3F^U7XO_A!*'76W'%IZ9/G347\8]6&W'%/;!H#$:-(\M18)Y.1"1#B;Q60@'M\R[O6>=2NS*+1NQ7H(CS=FK><*Y/+.;%S!Q&1E\YA:2+W5%=:+ MM2`V"\W)RO6L_4;!!D\.\*[*6K%J[0:X4=JTP;,6WDYZ_'%/#O*L_\'Z#9O6 M=W596!J->7S#.L3M^RU!.QJ&1B$[6H@>0T^CG>CWZ"UT%)U&%U`+,N`!>#1V MXH5X#;[._]WQ^IT%_3=^[F25[LA+Z+87]N!])OF..MAY_G_YLP+A$="W,(PC MC(K!8)#@6M)D-IIQZ!;-:C!%*-2=7@W'=&:1WG=8-0H^F07E.ZQXMY]GXSSL<'L3$5A\!O>)0C?`9@%0LQ0+TP9S/ M)."BJ/M=.*];*^#=,`XSPKB4UR.D<1$FM,`BC0HWH9D6*1Y@JH`)HO!ZA)3< MSX0:+=(XR'TDZJA%.F`VH;]8I'T`/Q>4VRW22Y![RB+M`GC3*B7?:T)_$+!; MP$XK%S;?RIN=)F""57H7V!^P2GZ`.*OT9X`8J_0.P&"K5`K01X#+QMD'VSA? M;QO7)LTO[`%X2\+1= M&@\R/0!`.<7.V1^V\V9;[+R]RW8N[%,!'PHIFLB5"2E+$%=PO(`PQ$E@K;(Z M"^8MP."P%KX0)*<%$$&Y25#.QKR]1`'#,2?)LDKU8-9Y5JD.8*95JC9SNU0! M*%8I`-!ID?P`(VU2*J@499-TR&VU2^F0R[5+,P"6BYS3+LT#2!:%L2)GL$M3 M`6X(]D8[A],"#@J2MP6\(.`7`BQV*<9@0AW0GLF$/K-)')M1DPV?6PIRWX5>@4+?A91ZPIPTG`%^]#9<#PWD;_@Y` MG0W_QP_9O.;LU3:\$/A.VO#SD*NRX<^`Y*@-[\LUH8#(O6?#ST"=7S"4"C@@ MZO:+NGTV_$O([15U+XG MC@!(M^+O0GLSK'@B\$VUXFLK8:5:\16`9"N^")!DQ74`XZWX@Y5L\N$*@'@K M_@O`*"LN!1AAQ?M7LAF)]P(XK/@W`(.L>"=`?RLN`(BR8B]`I!5O!K!8\48` MLQ4_N9)Y6KQJ)5L(.!.@PX(S`-HL.!V@Q8*_#]!DP:DKV8:))P'H%J[G)0O7 ML]["]3QOP0CZ4&?A>GYHX7I66[B>)RUL9L'`]WQ-\?@O7L]3" M]3Q@X7KNMW`]]UFXGGLM7,^7+%S/%P7?+J'G\T+/G4+/(J'G5+%64NWX'@_; M&'@NR8Y7PM3X*[Q-#ZX$F:4.6-KM)JD:EOU7)NDD0)/(712YTG`KTS<2WD$K!1@,$L(W),QC#L!)."=,.X9'@GC?N(^`=%AW*GV$;GL<)Y; M$BXV&U'X]S#N(P\)]NWA')X24!XA187![+%A%W1LJ@TW/0F]M>&/8/(EPRR' MR9=DP\_!Y!MOPRF0&V?#G\"LB[?AKV'6C;+A2(`1-AP$OA@;?A?X'#;\%Z`< M9,./`U]_&Y_743;\/O!%VG`#,%AL^$LH--OPF\"GV/`O@`\)R@XK3@:^-BM^ M!:#%BE\"OB;(`5^C%=<"B0ZS%?@N6;$;^.JM.`_:.V_%@Y]@D0Z7\J$5YP-? MM16KP'?2BM^&PBHKW@)\1ZTX`_@"5KP"^-Z#Y93-_#7.!2BUXBS@.V#%3P/? M?EAQP+?/BLD2?F\YV$SB&U^TQ!EZ2WSC:\4\]Y^8D]2*W!$L'8>Z/V&^ M6_P*2P,!=@KX,98&&?AV_1Z0K,/29@@6=LO2AY![0>8D12*W5>2R92YSF2SU M!Y@O2U%L8Y>YE.$R5RE*4!IDKM(_)=[LIT+/OTN<\KC$95(!?Q;P'Z)C/Y'P M#("M@F&3Q!O:*/&&[E.DOP#E4(6KVU_A^VV[S`N;9%[XGR+WD0&. MR=(6`"KC-^:"063\"L"[@O(915H&4LXHT@J`_0J/$A88I&J`%`$3!$0)0`9I M"QLJ(SX]'\;6R)RR1%`YPPH`&.\]] M:L>?`%2)7,#.ZWYMYPP[1.%643A7Y*8+ADEV_""0)`A*V/L_WL#W_O_]'>M9I(KC0D`1Q1<#]-MEL(I M$Q5..5;AE/UDW,@,(DRN")-WA/&Z6&OEA:^(PE^(PF)1N$H4IHO"J:)PJ"BTBD*# M*/S:PF?/=0O^+8S*5Q:\$.!+"^X-\+D%_VT=3!MXC0O@/V'+`OC4@C'`QQ;\ M*00U;UKP>9#R!PNN6\*WN@\!M@B9FP6X+?@$4&Z$791%0:)PM8!5%EP,A8_! M9@JPU((?`S!;N)XM$5S/Q@BNYT0QR\T*-^0-F8_T%9E3GI1Y796`HP("`MX3 MX!=0"B]60]1U0.3@8=P!R#TO\X:*9"YZNQ"=(T1/$W631=TX47>?J%,$E$H< M"B1>]R.1^Y&1,Z0;\3.0NXSY[*&8-_N^@,,"_BS@;8Q/_9"Y7UP)\)HH_*.` M/1C_$0JWB)R;[&C'9EXK)_K"@?%#``P+&"+A?0*R`81A/`F'1(C<0XVC( MG4%`$^B*\ M#.`>A/="H0WA7P&$P[L(`$9X+`\`MUQ&@*L&+NP3`V_HM($W^R>1^Z.!-_L; M`V^V6%#F&[C66P4\)<`CX(<"U@E8(R#+@#\#7588IP0?9\0 MW2G6=*N88/`F+*L[+];[VZ+N-5'W.U'W4U&W6M0])NKFBCJ7J(L4=;^$OW[9 MSBXF.,`U[SBH.ZUP>%_A?O`9P9 MM@,V,>^LDEN@!,B5RIR M,^Q2$Y"X[%++O`Y`CI68`G(Z2= M9AZ5[(?V9L.5"8!30)V(2M9C:?6];&)*;0!S!:1@:2J0#,)2'R/,$"Q]")0V MD9,%0`"28623G3/L$B09$@[_/42X$GX>($J1MH`4BR)M#F.VEKP`=H/T%L!7 MBG0`H%&1]@)<5*27POAVO1-`4Z07`8XJTBZ`0XI4`!`G^.!4_CR[V@GCS4X7 M,"!,.@^6^-+,E?C,S'OT@8#WPSCL%_`?`GXC($^PGQ2PV,HO$:1P/'8VN*YP MW#$9XM9PC.&RPQ:./X?H(BH5D49.+LL#\$EK`@GX/7 MC`?_!'RK@('AN/,E6-/A.&\WN"XS?O@%<$$"GF7P[^YHN_X^_^;/G-ES#WYO MYF*\>QA47OO4OK\Z,EFMZTKL887V_:'Q8,L`$?\.+>?FB)0LS%@"M/VP<9(=F M%QD<7,8@=MNK3F2BQ@8.LK+FU_QAPQ$Z=`[2T>SUJB&+EL"K,^F@J3%:[<,8 M2@8S0DX&U2;0;2$\(6,4T=EC=K/&2^HN/7:8W1MWR@4ITMASA77/';5XLZ=< M::5>3X3,5:^0<=#BO;B].XTUEU5:H\_MCR_T@L=G.[YDO_IKGI5;5.-:K7W,AY8Z[V" M![:6E4?>D?E.OXAR]@Z1\JU$"Q2@8J\7F;^=S,S(X,TCR[>361@9O)`4^>UD MD8PL4G5%?3M9%".+4EW]OYVL/R/KK[H&?3O9($8VR%?A$);LL5Z/]7JLUV.] M'NOU6*_'>CW6Z[%>C_5ZK-=CO1[K]5BOQWH]UNNQ7H_U>JS78[T>Z_58K\=Z M/=;KL5Z/]7JLUV.]'NOU6*_'>CW6Z[%>C_5ZK-=CO1[K]5CO?V8]>-(_OJK\*7O0[F,[>27Q9;I[J:5G457=<;?95F/G;D?KATZ'0V%IXU]"+KS63 MOOIKW7D'RV6Z9&R\@OVQF$%_!4*#,>UH'UO>:3<]ZE!^>6L4?WAN\G/ M;V=U.8/R+W.:OG>C(7V9N,^YN`Q%R'-@_?+?_XT\1Y<\H*FX&PUA*H/>=VBM M9E@*HDRLN_8=(T*AT#+19V;>T*E;W4]1:G15X6]6R@%9AMIJ MBA%25A^-5*>W+,B8.UL>*__(K$ZWJ'.5L>>>N-B[,"E:KN[]57C(+14\4MB9 M-LWS^:(EF9HGRC*)),,4.1#\GBBP\55)R,NKX5*K_1PEMH(_,[*IW\ M2QF"BL_9(C,9\SL2I:T/0`IDR>!O8,!T**2 MO\3;_154W])>.,IWMKRT%?B7=91=E-07DOM!>GX;2-<+.D.A6]]B-><.`1V^ MK1W(;:ITMK&&_.SK)O3^\-+OGE'A+`M$>AC+QD/6-Y%]PA\5^B:R6M3%%#2" M`4/.MORM;>Q+';:..N=L.V_=94;PQW,OP:>^'P2<6]8"5,R8?1@OLV<+D8)_ MO8L,^::,?5S&`29C]9TRXF^7<=C+ONBBUC\."O4?1-U-,4:QU58(1I[?5O!, M*1`&+U88&.(*PSL`4RL,?P:87F%@+S8_6F%X%R#=#W_`CG1S;S``&YO#+)M0 MNYNE=>FN#;&ON-CJ4)>U'>*O++,/_=D(/A1E%R3R#!N68(U_JA'*#]P#2J!72PB6WM86Q];QWS"Z;VN;`S2=WQ1R M-H&^A?"7.3YGAQ+\--_95`]T^8;9&Q8:DQ8ROXTL@Y6H,\T.C8>N^\SXLN01$IY_.%@!>Y-5?$L#Y_G;4LI'8+8^O%V10,4\%2R?TAZ=O: MA.S/?H?%$*PH\K:A\25U[0E$^?YNY*`EYRCW"*J9T3P MIQ:LU;*V2-YAX%+B#/N[2RZ!5HG.\]NL?C8L<<[SB<[J[5*0]3C160\IJ]_! M*^H3G9>V&QK8TOU&TWP^@M3D]+M6F">#K*EK`CPV6E8]'=/;1B3([7('UR[A M*YO4.5%KG)<8EPQZ1NXQ;O=,0S[PA>5P]<8_(ZLBMO M^NF;_R76VKO,C4IGHX`FX6]AG]7WV1A=O6]K/?)$J,YZXMS;X#)U#5<=FWC, M^!W7ZG1;!*/<)S*S>6:_ZMQ/G`=4Y[YK=<19JCKK[']R[ML1V&KK2K+BYX/A M73E(J\[SD-HO2'B2D>QB)#P':=7YO.S:_N\3AWRKQSV%<(J8JWR#NE/@> MT-\NT7F2>9Z3(>?).V0E.D_:2QXQL%'S$R?LW>\1Y]$URTXF\\7%.MI%.!)D MPJ#J(:`G[, M^6_JD'!;.O!ORFMO2Q?>EGY.-%)6;V"F98I@Z'F]/%\G$NO&;:3WWY8NORT] M\,YF]F&G'V8X=K[W_Y(N_N%_UL4+_Q>Z>*6[BQ/^AUT,3KTM5_9O."+_#H%(0W]P>:&SJD"ZK2[B MW^A!;DNG?9._(8D'1`'"NGB4L%$\P+M;"MUM>+F=5=[DIOE;=?UKWGG]6?;% MQ!`P;;V$/+U@C]1?,#/GMY=[Q4'J,M8&[/KZ!3.CK]>W<+P$6ZGJW/L_W)6O\?\LO24$I:+M]R0??4N?[R]HC;YH45@*!G'\X^YY*T)QU#;C- M/(_+OTEWYT!4P?'X3O7&_#?5NU,YF,9=;:GSJ^+2.]1O-LV7%C&[]_,M]!@P\ MAC%JXQ<(?GZ!$(!/7Z/YXT$Q^D0#*ZAB-PI]E:X;A9:[GP?O)J^:RZN[)>^Z MP@KJF3SX@^*[RNL2-PK=NJ\Y+UQ-O0"=[48)`7W%E5!H-?MZ3'8(WZCHA]AY M\*B9+\P/]78CXP>O4U=6+^L>B9^9*YV7NJ?@I1"WJV-K_\,.MF',OU1VP2S/ M;V2\-X`W>)ZE%-#4K\-'NMYI8N(5_>$F.*T[FU+9O8,X;O^KU'![\6_8R?XJ M\XCEA]FYGB^/:S?@*$72(_4SHB+YCHJR"Y$D4C\BJMA:N;.*77TU52:;1?P* M*8M(-<)1C$R)$G^B+$OJ9_TNYY0*!C=DU6SG4LNV"Z MM[RLS80-,]CU#*_^V==WJ4Z'&C_[1E/];2$KJI*S<#/R6G3S&N:G@B(R9&#R M\H>S3W8$];.;&CVWN]9Z9RU,C(6BRG1SJ^*#]8UCO'NDGY4F.IO<,&Y-H>1( M5IUNAD\LDA:63%>"5<7++AUBM)Q!?^`+9K[ZD+.^X3Q80#_T.<^G^V_P:?*1 M0IO77[6RP\N.8QX7L;(2U8DR--Y(3^#"A#Z(Z`9^IN3C\[:D)YGI'TX9EI9I!4Y4V*@7V:-.D?6D%T MP-,'DL_:6=+=._Y8@26F(0=F2H42@QO60"+^\VB56+ MTE\XDQ3S0FA<3$5J#!YR9E3,F8XS:V.4%XI7Q9AO]SW\^W1G%YR&A59PE7^0 M,_J]T.*BA4>MYXJ?512=[>IA'?1P*O0P MD7?;W5L=W=W)R]V=C+]4,)PINXRI"$Z%5)+3Y(RQJ*XDL(!4E35(5U\NK/)^ M*E_=N]Q$VKB7;'@4=&G0(A'Z7OGJH;\_:S^&D\^$=+`.RKU&SW3JLDB!?TI_ MX>.MG859(>])_+L?]1]S;K1Q"D)GCIUIZRK_W=,M'Y]I6[B,?IP:H^A_!O.5 MFQ%/OR/29ZY^7"Y(?Q*I\V+ZSU&7QO2?J[,O_/4= MC5S<-9E\C1;5'1/CG>3PR*Y@FYH:,V*XCSD+):9P7LRH0B7&7$VNO@]20Z43 MM:$UU355!-K9$=AB2@AEJUMBE$)WS(C6"MG^[#HF.11RKR9M>D(O/@F6M:;& MC%31&Z23![&=?-JQ_#ZK]3&;#6'`%K17)[K'%\V+,Y$;"L=+DVUO9>N\M MUH1`MLJZ^#`P-]P0C=EW[(`$M#+"X?Y'M@_4D3P?0=?C1==!!0._Z!IKV`PK M*>'8/J_'<)!Y'W(U_U.VP$N3[NC4"V`DI;O!KK(?@Q$*U\:,(E?-^ITVL!>M MACYTV0%Z;03-8I+`3;7I\9%\ZLO>OSF\,3';?4DQDD?V'I=];)E``D,"LX3$ ME(\$PN->4EVX-&:D);F5RFY3*Y7)KFST2%WP-!,.:/FH1RX4- M(G<%.H$*2S*AL&#/ZC60::UTN!-)\P%4F@I*U]8<)U$Q.VJW6ID=E1B]&:9G M<'!A5`QI]AYWO`N7ZW?0;:E+",#2O-G(`E)VF&^5M;PE4N%K"[D''V;>EU1! MH9L55I*K">=(E?X$5U)HR+9@7V-4.OD[K,]+=K8=@?4L,#11PO>.L'=/!K8S M[\,>DY]-TN!G^Y+=]ZN#8LCETD>ZK%X!G&:P>_$;W#=G@X\9Q5;9'I8M)S!V M!*81\*@S('F+CW)."+"VFAA77;#*_NP/V';EADFG)X2*+7$)M61&3%0PH;"_ M]\9`ST!U;4PD:0<[C;S,NSU%_SE3O2F8Z+UA=8>14ZY"\Y0"2UQR6B(LM)QC MK,'"53%6`A)'UN"_@S"E]:C#`[[1ON,';(\$S7U'^_,(JJ$`9,V=`^-6O#0F MRG^%!5OSH#WHZT7]3W;N$V&!^@-@'SI';PGQ':C_FLAU,RLFYY=/B`=-(F$O MU.$6=3M"B^D<4J[_35!))'(Q#6Y>,'E>RJQ''2G?38F+&_N`8XYG_>AY:]9E M.7*?RG5GK1OC&/'X2$?*AHU/Y:QY8K7;L?(I1Q?#M/7NK)SU*]QK-JQ?L18H M/&.":O7>O@++F.G*SY2`:/-[#OFXF!SVQ_#,K>$P^IPW,F3TT?&2B-UX;^?@GD"X8O951E(UO? MSV>7P7ID]L2%J9Y)WF!\05TI2L\N,3"V6'7P4O8D@8;`,OD7$41,0G)9T)+- M/'#I][6A"[.+SF4?'`6;6/;$E"F><:3/43`>.:UF#"(71YYB)(RB:#"3"$_& M<>7(UFQUXZBRSY3LHC,'PDI1<%'VHUQVD9[M:T-N8_:>*H5U MPXA`@I8`ZP1EAQUW2Z4XNX@KF!VK6EF`&>R7770V^V`,*CG#5"DYFWVX'X+E MAWX_A_=V+GR6T.S8HL&-+M#M>_,9[__B[5W`HCBRQ?'NF6:F@<%!&105!2_UMG;.;B03V5QN%,QTQ==,=#_KZ=T1W_I=SG4\\9MWJ M!OS;6K=5<]JTSK_.<'WPPN%S\,P,QW3LK M`+LS=NS=(5@K^3?P4F[+R]E],0O)2(,*M8KNY>+1_@]3*+Y/O!S3N`"U?@$L M^.'Z#).FDE(ZYBQ`=9\3E6 M_$I\CE'"?=F1H%T/2Z6,N)D5US%BB0'TX"A:[(#A)@H7O3TZFKI1S\L`O0C+ M]._1W'GS`.+NTJ,RX:.2GS/P6LBNU8NZ?&D5(Y618E8Q*Z`,92.4_IPA::!D M5/(Z9MW3TG,SD@:*'U>,D`H"*YW/12>7F- M`J89IX5E?APW87XR:*)()$5ED[%B/T[/TLT2)4VPN68!@D3G\FZQ05K(RO\* MVD^LE[(9L$7'2%K4)5*R6/-9P`[-P02E6CR@`SVQ0!T.]##-SV.5C]39H5O\ M5GX9%30IQE,%_$EJ,6[!MS,="C%6_B>9/,GQD,B9WFU;SU#&RK_@Z#%&NEM4 M;-6&F$ZZI;P:U9-POB.^23PB-E8I4(%$T#`:J(+V8,)XEX4+A9$'?`A6\8!5 M3+2*:S70T%7.`M;VH\&_Y@RF:)C\(,XR,B*(ES04M../($4@FV;;05J<08,;_7$1MA@F'S7D@?.)S$;+^&I"@0PF!M@&Q*G^%IHG+/V^``6([-B^A M50E,JBX.!.,8R.WB.\7E#%*\E0L0\UE%IW+#SP#G\FA)8ZN>59NN3DS3SZDO MU5>7WD%J#`Q8WF^39XG+VT1-+:/!&HD-R+N\0<9QLZ4\LS2!/N*8ABK%YF:$ M?DWQ1*&?73=6F/U0`/8(L$JV-ANU+LL[J-F3B7[G`R0-($IP#4I"CJS`-!`& M96"O9#"+;J`M_?.T'0^&@#.'M2FL.&&0P`V>C7A;6E?`TV#-=_BXH-J`IW"N M!\PK!],,YM;K'I8F8525P@A?T9_-]YL0U6`)I@-"B!Z*JP'A:1@N6)7>C9,_ MHW;H#B;`I`!K`TMMK`0FUMI^VX^L&*IHB%%UPW1;EF.;+:.!QS,)+@56I+'= M`URGV"8WT(01#8-Z>!P:;==PENS&RG!3)332E8E0IYW4?$HX.&5\:]>1*^GY4'(*$4@@&Z/JF^ M)&#W`!$R>0UNBP$S]`W1;>ON7O#!9O4L*Y"%4"DTACI";;R M`F=,:H&IH%*L)WV$_Q$(-%W2.+/[Z8:D*GXB$JJ&$>\QTW=)L\Q.PPS174LC M190H,-<3C<_?Z2/B)VJAH[;(_]X_1$!)I:$O/0)HYR>C7'K93S^W@$EP5`59JM.20XKKI?N;0?B)ETI M"1"O@%X7PU3E`Z#_3U5`8:``7G&1)?:5I`?Y)\Z!==RLQ-#WM%R@/=125<\N MX#MS83R7T5-2:#NMY4;90Q<`<"V]@-/:U$<"+#3PBS@KV(> M[OX%7(R(?J0%8@XKYABXB,2<:/!&B3DFB(D0?=B![JM)5^$O-$.7FY_7>C8'W`,%0K^6 MHS,#+W`!,OZDSANM9X_?L1ZF\,"ZLXKU4#)87]:JTR'"P6WNC_76G9II!Z>(DTS8OJT!$=BE"'HMPIAIDT=% M;0QUAC^@UE1&5YT2/E1S8W25K8ZQG;YNG%KE3FAUAG]#[-U[`:4M!,.,;1J^ MKF<[<4`0W3>FZ]YJ8;`3H^[8B9XC MG.BUWX_3O^7NG:.PO1=VXL\VR6.%WAR>^724$BKT3BUF/@U3]$)O=+'F MTP"A+ZQ4\VE80I.]17K^USC]ZHY0@G`6RI(ZRH\,5D$=KL7JY("-D*P8E!S6 MW]8=4)8@NKWTOA*6A@D>%% M?A>2)U67L&)#S'ZQ#4T/%4PWO&.!E[QM+FYEI&#ZMKT?7=&'S\.853F7;*1: MCK.M_#R=6#UG+_XFV)Q]DW$C7I^]`28/)F&.A@M*S*+7!8B=CBS:5J-3Y*0^ M;HR4H8%9CVZR/L_7L+Q&JU&J]_6(3ETE`OTMGMV.Y@/<130 M0M]4CDGLXVF+LX"N]'*!N/U2;$Y7O@(75ZV:.Z*BE9LI]$5STX2^0"Y:Z'L8 M7`/KZ:FW9OH&,C4`!9T;,'I*U6F-,W(4FMG!C@BQIZ*59^P3E/&B7*.A/)D@ M?XY0B&WB]*+LN0_%\2%PN6G$`VI3"U$/;4<;4`S'O\L'G8BWV#I&Q[UD%!D( M-%8^C99AW>:"\BJT9\CH8BT_377`2&$&#L$Z^3\R^16C^-4(4Q@F..GRE_?B M[EXL2@F6=Y`/U)BJ&KA-&-`4CQ$&V'4C#<[MQ-@\0+SEPZQUW9*47].,0=$;'K,I0QXU5%VUAJE@WZNN+W!W5;;R`7MPKN(()S3KI?G@ M^\.1CKRVZBR+Z)2/(0.IONHD0]M3[TD$5*KD@<="/%6;05;[MCYL9AT/AB>T M"CWSBB>5SA!ZK,6&TON$GL>Y2,];*&@]J[FIGI=)*-/XO`2!TC%*N*V,!&GP,Y M3VCSP>D?FE#WQ.UBA[2*E3])@T33A?Z9O-;^^-B:K-NIP64)\+KTRN/]-18[ M`*%/E3APJ:K:+S]7/.)--]%\LB.^PLN%"`.K.588R.2@5UV`;I`=/A\:"1VM MYW&>%1+C>>U\I5M(C.-HBV-"NCW"`O+M13:+1T"=/)!!42OKI/P)?8#Z$YS-XOH2G!I[#?OA9>%^$IPN>F_$O??0? MXW_IT7^,O_G1D?AG0WEW/D91P:O!$H7GCU:8P#\.(^(:BNK^+44]#/!$>&:N M5M^[K>I[W&_5]W/P_!;R+P#XKP!V`IXXR)L(\'N>`'P`?Q;@JP%>`K#K\/P: MX$L!OA'@GP)<`GBY'_\D*+L4X!S`/P1X$\2]#_"W`?X^P"R/J^E>`?C'`+\, M80_`]_GS_P;@7T+^+P"N`#P48-?A.0GP#(A_X7$\>$%1QP#>`?"L)_%\!P7$Q3]U`SZJ6/TN*E'?:R%N_+#\^/UJL1K&]_/P/E]\ M`S[X_5Z)^GX9O@O\^/\,9=\&<=7P)'!0!@]MAOCC`!_[>S5-(L"^@6?JTS?P+_*75>N''X%GX)D;\$?]\#&\^NY[1&KW\18?/]?FY<-'I/3W'%#?D[<^ M9-;(623#JI4%DERP8GEAP1;&?-^+.$3?]Z(E%/3E?1(%R/I`5^9(^VVN2$"1 MLV0H-ZL6!XKG\$M2N\0G;BM*@1HQ5FF)SJ%+>IACK2)*?^!2H2!X%*P,V6?UA?G,[_Y0!$@@U+7;>/, M*=.Y.2EQ7%3*?=P=*7.XZ)3'N%^EK.:24ZP]WK5L]^'X3ZB27#%7%\8WM3&)0PX@:887U4J=U M-MW-,]:]-*7MLIW7DWHZ[_E"ZX7*OO+`2IS*/GQGY&X*U7<&4]4VOF02G&A* MAM5-;5-Y!D,F(\&U&:C5!*LO@YV2S]22U27/2V"!JWF[(:^VJFULR4222TOA MCJ!\YJ:,89Z5D,,R!_C"6&&E?V=5_AQ'/J84L?AQ'_D( MA`_C?^\["4861IY9@9'EJQE?+<(8C^'G,7HZP)TVA\UDYE1D4GP&K`'H)MO: MG[)N;0262M>D_EWH9.GO?-?XQ7YU6@;K3@`B"8Y+UZ6K@PEL^Y^*TJ/S_.Y6 M;=$,\M=,_D:3OY'D;X14[Y8F@[>*?(62OP:W<>_D+,RCOLW^=[3_'>E_8UXU M9!H*A?K?!A4K(O$'S(.!Z,%`Y&!@J!(J)G\P=#!@<#LF9^4+9_5$UH4?(@8% MO1V(MAP.=@IG$M'Z-3;^V-4B/10^P^71'3FC;8$%TG?`X35=TCF7/"6?![(X MY]X9"6%DO_PAG'*:XUM=Z@?7W@2N&C<"_-X-L)P8#F(T>V`(\]9AL$B$';X^ M!%M[$]H9(TO-17#F4\Z'(`6"`T>"[[HI][+P$>"PFW(G^L$H>VT_(WLC)!;Q M0&:Y?@+4>AULZL7"Y-+QZ*_2>:R#$:O]$:.@7;O0PIBLLVYUX2+EMFKKMF;I M>N>[^BC/KR#Y=*ND`S'.I*S3**UU-J7E#<[P-G`/S1&7E"J1$*/!F)Q?^V." MG.$F?]C3U>O'+IV2!J1KG>]*?9ZS$`?])).:;H7RO^T=HJLA8B1E3HX>09D+ MXT:".T<2[M`-L/P$D-SSS`TY^608;#'"Z!NP5V]"NWQDJ>O&C>1'\DAPP4VY MQ9',3KHI]Q-A_T-N=H`#R_-^CZKF?'?[2AA?B0X+1HT#$Z$SE$%^<[Q:%_FA ML82WF/3%#-V+&E3&#TO_N\'T9C6]1]-'J#(=C@X[BYZ2J\>.;-OB MT*&V#2;Y\TU)5IEN2;+Q1A*Y";?G'.L=4,-'8CD]^I8D1\)'8MD[^I?S2H0BIL.)?GA'0[_)8JT0,GLZX"C: M+T%#JH1U2$75\TF7O\_&JWR:#N>[/6_BZ38L#=:#L3`Q"ZP,*`LZ51;K2?1S M6[X>?B/+;3T_V]6G2T4,;)_`X5H)=D:^H6W=A;:,<^.DR'??M;X+=7\#![XS M%T$GW-9U4Y]6DW*Q-R6%KJZPV"8IDR%=_4>OJDQ>0U9'F48RY'*(GR&#"0;" M1B9@QMR4X,2-!/(&W.FSN7L8_GW#H"L0.FHX=/M-R%??7+H0-E(8YMZ<8-5- M&%XRWI1@SDT8GC'^4G$BF+#S=T+3/1]>^X>=_VV_@,O+(+'4\%IR-KRJ<2RZF%U&BZ3@&C/FW8A.2G'L_K5U6LSH?B5!)_%*R2>$3DU\:1D?(B M8*4GSWLCKYR,,1>OW80M=P@;1`QR,>6GBG@YY"=2EH7\0GY+D!OU![RC47]` M=XXSJ_IC1Z?*>R<7%RGIMFBASV_$ZUX<(C@66>+,2P_1NLIYCY5-SV9C6T-LZZ_3M2 M>3&3&^Q6##B*/(%^LLG_#D.=1^^OP&DHB(9-GW/A$>$Y!$\83/`*X'G3/]'[ MIPGCY.Z,C'6)NMHLU8*OS6)]J9X_7?D%(HDH:G4#CHD'`4GV^M>_0224Q;/L MER/Y6\>XAP%)3/('._TU&?/+D>"V7T#REQ:JSE^3@Y=_,9)_ZSK.*/T8D`ZF>C%^*!'F#D@@2>,O<*7YP[N1I[U!% MHQ_8'PES^1AXUL)3"7/X0_#<74I1?X/O$\_X%<-S$V]TM?_9G(QHH?"Q-]#( MER?\K^7.W/&/R>/1^A/\[$SQS"65$KJUH/G@R8'GC_#\%9XBH`(/3S^$`W_O M'V)01^$%$;8V_8@)YO.#$\S_`S)]:QI&IF\&27_3>"._/OZ7T&_8L$-R6R&W MY]Q%O\)8/'Y8B=G^#Z3+9+^7:,[O?U[YH^F#&@IM']1/Q/8AVNE_2`-UI);C MP;#QG/4SZ#^&5:`6PD=^HD($"57F";F(LYK:3"I5BR\&(;69X(N^,5>*]7E^ MN("-'QPE@*V]S,U#!T2.#[QYD('(ZI]*^1'S$RD#]#^1LD/G)[!5>FLX>=X: M(H]GX075I!0A'](5WM&$KC`(Q9E'9/1,OC!L_.P#CX6'NC0LQH,Q?[KXS^/; MGU^O\-*A2$'24JLQM*_O^7R+=PYV'N,'*3-GVF^3\C MSV__EZB&U4IB_L]J9?E?H4*FK89!Y7SI/[8AL;C_(7O04FN6OPCV]S48*WZ1 M8H2YHA8GBAFJ!2CSS#NE=A MR#\Q&`PSMFV@4#Q/`@:I:[!-F,(JS6?EVP&[-$"J1"S_B4$7-K#6V"9K;)T2 M8MT-U9"R65QI%128D4#-I'KRA>666;4-&T*#S@UE8$B&X$9L@J=75AT]C-0. MW6"&YT?X7IJ;;Y6*`9\7\.G]7])"1II0=1XV_*QE<;SBHX*;8#.6ULN'55T,E=Q2H]9K M#3X9W,)I&B^ZK8TG@^OXD.!6/K"K!K9JE,'VER7+MAR2>JIJ0ZM\H54]H;`X M6T8)C*X*M6H/^P.QA[G)):QTR=IU_%^W'+7:>BREH[07K(TGH*2C MTK551>[/J>"Z#<;/?5TGNUIM)ZGR:VA$Q/J$'HJ;E1\+ZZK1Q6.#7<97W%(? M?EEX)K@WMDFJCFTR?N0.ACCC1PW&CUI6:-UA1X5OJ0TS,(VIJQ;*V9UO+K@*/B/DC=T]C2V%PR1>OCF<8#C2X59\EHC!U*1S83:21%;1^VS?JE MKRS6M1M+4SS+EB(KK.6'0"BR8./V6D;K#8[G_8P>C"W&V+OXV=):G?2L[NZ! M?>BY7W\?R9IN9X&>A]UA87.F7TF&K49FO++B6Y.4/0*J?%:^0F\4+9&$>R$*& M7Q:207RF@/A,DFJL6A<_%LYUE,O)(+[88E>LR[H75M]A`^EG-GF:/U:`V/)# MOC(W9`V!K($H>33*V1*I_><%:U"L>OR!8!\?I`4N61\,;MH`\EH'GZUA7NN" M8"]\QO98RVM]J>O'6\M!"(K'2#W6?;XR?_&>9MR::/.Y-@7'NF*;P-K`FX^6 M+L*_GP.FULHR5'JNFZG/.O76?_94M+UQFM&_@M%75X,]MA7QW( MVI*K7<X- M+QO',Q_3BL[:=D,G[ MC_J]]K"UW#.06FRPEO<`P0,\?R0T[AFD<9U2!GM@5O!5;PS,`2"+M*=-I?!-=RBQH2=1F_4[2C:,L2XL3FH)=FT([&K>[=N'IZI70,1NV,)`Y8*LC35^><#A^3AJYL$C;8Z# MQB\.:NNE!H5!GL"<396";!8W54GUQK]6!U>U!5?UF+"V>NY72%@]I[>65U$I MRA0D7%`YA'YY#N_L`YGZ^@O!XJ9"%_!64:"!,+0L4`V\=;=]$I\!WP M!ZO-$QW=/O]A=>XR\<*;.? M4*ED"BJA8..'#09M4]6/!B4(@L':)N.']<%82(OR"*2C]A??#=S_>N/M0`X# M2"B.;N!;BI8ZU`&M!@3VR(^@RXF``Y^@]RC35515/ZJ8D,P=95AJ!A>.P@A1W>U4;*_3X"!.%5&74YW@-*E`M`"EE M(?3'D`";K#.(*``23`!/*CQ1N!D+'CT\6GAP*S_PJ`R>5'BBR*D/`%-XMRJ` M*=RHA0D];9EL!"N;US%6'WS6!@>:_5D%_8ZAF#/'\+>D;".\:-/)NBG M-5:%>9-KC%MBL(!QP7!N-8Q<$%NLA8*,%6.P$#GX$&>@YS%#)<`(K"*)(T@B MK!G&RF@\K3F`C(&N5&>L",7C0O-4_TKY@^!?@4S0?^=J&S_O M38T)IEGVC9J*OGT3IO_]J3A-UIM]J3-?>S+HS5VQN_OV_9Z.?>7VV[>=[4OM M7_.G$\7F!7_HWU?UD?+RU_"O/_5*^1\_P'_7]_DY(?A2ERW-E;JMTH.LM?$T M'^]-#Q2X<&MM!OCB8*<`'LFOU:*7#O;<8R2E;A^@U`T'"F>%@V68,#!0>#P0!`0VT:7RL\K+"`7YVVRI M%#^Y5D_QTK/)'72_K9;^QXPEOZ^]P] M;^6OKMZ5?NS3$WNQATAZ."B(R&4>JIV3M_1GX86@D&);=V&Y5358AWWPDE,A MUXJJLS"VGY0Z"U?(*T=41CA(2[7.\.EP+G@/KCS)C\&VNH8+)1%2[9H!Z'YK MJOXEZ(4UM\UZXTGIE+P?'-(`BUR#0\@->DJU`'L/8$))H``6^09&6!-MST)DF.U^@,V)C3YAOL7&K@?2UL*;B=AAH6A0EU@NCD`Y&'XT2#C%Z M-"<6*]<*)26.]UKN/;]!TG<+3=\TP']V" M\URI88[UMDRPP*MYW8ZT+RBEI*L)YJA+H!49>.'X>:&AIN$\SD;AW'L&$ZS= M,93W6%14JVS`3X5H^\9C,;!C84<.),3=M"\9D>`,LZ;H1=V,"J" MH90[Y@;5W)C)!G6022QLI7_)D^7Y_/6/HNL']@6N+ON\NH>VU-M5U>Y6%=^7LX:5-IK M,/$3%,S9=X"#&ZS/94N18S*L>5(%4DN>_`YTOU6W=`GT\^_\$GS^\D?7ADDA M<)'T1D`16T?LH."Z]1J%DKIWHPRB/01VBE5QV(?+`#/Y MO,<,+[P"`:;MK+Q&C2XBMIP>`U".M2VW9J/4$3X&"ARH?.F3,V7;F'H2X7Y3U26)[]:?RCU MQ6[7FTE_3CUV=-_WV6LRWHS_PXZ3J661MW^0&GO7L>_W;?I3TA,YIL][]JJYEWP=?[J\IJRU]\4SJ M'\_V[M^SZO:%^/%=2@W^XA'R_[5]@_AZ4P?Q#0S#C`8&[@QFX+\`^$]' M+4%E)+7C!2[=?O$<,M/12-^(MR037;4/Z(-:<0_1BD1A/0J[0(8K+*EGI7<> MC(X3C)S5*]?`UZC[1()F-%['&G070:%G5L`3EN MT0[>-F@5^?Z"%#BFIB*:#/4=GD%;YPQ_%7)H&^5NUXEB>`N+B$ZS1?`-(F5&D]@7DZ' MF6`31DTHS%,G@.$]UC]7'>7WMA`?@Q(@9P^77>E['%1@3(GUDKNRP%VVE_34 MJ]?5#[))_0?R\5+X<_._?MS]0:4O]8>CTH]GJUZ1?*G/O+_3F=OQJ]=\1`FA M0O*E+B'*#>3'B^PBU@;9VQ]H`V.#UX*EP5F!01LF+%;'5K]Z14X_V*YRFIBZ M<*0[M@XO#@!+O<^76DS<&V%UUFSE$@Y+9#[5JH0.3:&RE:M6F\+X&[>*532Q M=6#T_!1G)ZJ]?M>&UY__]SU;HZY,O-'MM1:Y1P&^MV_)9+5/D8$'+7A(!OS^_9`EVC^%4B@16"!JJ\,(R+L&NXT'GO>@<,V'7< M/8V>DMC@L#5(.K+320)G:$?PX M)5?]"-84:KXE9KHX?3`TIM4\G?X!7KRX'>#>9P8T^QKO'' MQM;&4S!)0_,8"JX'_^B5GL:3Z=SDA5W>QZ!'>GQM:"[P_2Y;! MU#!8J]3]DZ+X$F`!AF[Q$18/=6A$PP]G,AJ8>+>$;DF>^'?88S/V MX)T5+BX_1>`>C',[HN&`(\;MH)7E<"X>3QU9X1S[`WL3`_'J5+"3=7@^ M2@^X$LEM6WOPF._6.CD=9G#;&/-TQVK+])K,.;3P-3/=OMIBC'89F$]HXU1R M,8\]G(-2XUWDV)#_SCG=MFI'.%8&3GM%;ST@5F/U=DPAE8BZ4?L=M+X0S\,B M`HJ;.-U18)ENSYDCG.V;;B_`8LQ]_D+B79C2;XZ[CK>=/'ZJ M;8?F+4ZS0XOQL\Q6V)AO+7#OO`I-=^_LP+_^&QW=WG2#AH]0CV;*^T$3+31$ MJW=(;<#S]FC'Z^$\*>[$WX5'9&Q]0?S=CG3#+A@XJ?/B"Y MV$22EJE)R^%,4[-ZVP:>?95;1F,]3!0_W?%HB'>_A@NL33>]0`Y>>_:$;!<[6_H!X4GS`/#>^%=T6+D&:3"OB9"F_'Z-%C<-8`6H&K]1TSJ.%GFG< M*V)M0I,3:U+O>\@\5SDIC:5_%,=*>?W*0:\[E$M&["9)9W.QHFY_#L%N1?2? M(_HQTBC:(XZ2<@EZ*T2_-52@THY9C=)86S4KCMV?U^UY%-B/N49).EJ&W5,Y M_1XK>N0&<7@*\-:(-FR\\P'S?"#`;X`<(-L/F5-`HJI9WBQL-,.)LTE0VJSY M0+]9<$8O5*T_))I#6G`6\J8Z:.C01C@*78VP-`)0(-<]SOD^H/X]<,S4B)#= M\>BT0^@9[UQSRF`)W#\NP<&99PL#)7!8;2"?GX<9H[DID"->Q1X/V'/4/-,= M89C%YM8HITB"')_X$$EPYX@$&#_)@5%8"W"GLQF1]2"54X[6&<.R.WBXHFE2X6>IXJ#2Z<*/>NX27C" M4.A9PTU5`UG%&:7Q0L\#W!3\=N2;A/IHBSW?1+ZR34)=J-A@SR:?0K;)(C;X M0X)RU?&D"4Z[`_A)DWILL0:ZOR-"Z+N#UPD+3:R2+O3=1H*T\BNA+Y8/?R>W3FP$C8%IJL0CUNE2LJU: M8X43Z*>2.KA6B^)13XTRXK=BI'E/*.J:2_);(?YCTS%U"Q)<5_ZKJW&!'J]% M.21>FN\TQ3@C9RCLPL6.H/GVX.RD7OZJTS0#+XR<7Z.)7ZAKP&4B./ATJ(7SFF M.'/IBG,<(S8JG9`"`!OT,(U0'6^QCTY+ MSF(WMM70>',D+7`Y2`-_F&Z,L M3GE&Z4XI*,XJU<%QKON4.0ZKR;L_&N8E$\#H%B=(3_8KD=[]H5R(I,%[H#3& M_U[3KP3A85P&#N/^KE^PFGJ0C!Q3DS4V&DHC9$Q975QH?&$_AIXI3C2^<`A# M)<53C"^DTEB^\?FO8"PPOM"+7^N-%=_"VX,+LREKC14,O#W_B1^/%R\WOK"9 MU-U8\7=X>U[&Z)SB>.,+>/LW5'R\\877,/0;X_/K"1[! M/%G0V4)2YG%W>W+Q,U.YYLTRA7)F?SO%;M#Y8J=\""8X>[`S;VW>V@*'I[O% M'B43_G;*+P[X(=NJ@74)CBP3F=S!3)6ITENF]:!CS5!J*O7"86;X'EL]AKW&?I M5\Z/2%4)M%7>(BP2N*E2$`Z:058RM>TZ3,].['0<[/ MR>S^RCKN_-9F)\CDJ MP04=E[95:3S(O037=`>=YKF'5J\`'8V-DU:RLA';-QEB_1&>(!PPLTPT-Z;R M`C>J)FMLF=%J%T=:789S$IA,%GKOX(/3 M:K(BJ/GVI>.4B8#46Z/A=$"I:"706\-P+`1C,8&TE$UJV!P`NV.5@)AJ<:E! MV#QV)A_B6&J"%)1PIL>^U`0DM_5!/TQJWA0(+?H-IX7D1/R<6>.VMLC9^/L+ M3[/24@,M2RL9NF%K=8Q;/""N9/!*!1Q@P:X4[J>0WPZ-_"60R*Y)5RZH5RN( M58Y'0A*\J`J*'!M"A!\N.=(,]@TA[VF,%79LU@:6,E9@7Y4*&2F7E=)"93M+ M[L^">N8:8`@3:^RY!F5E,%JN)?H/S?(#_D=T@)(`_V%%H$+Y"_(4&*8VM M35.-5EKL(%`7=W2=M-]C5I@:QAR[YS&\7!+=GTDG M-ZE:<+=&_=*3$_[B$3"\#63WB:U7RVM$O`PCZ6#9O*3J,HO#8+8;YP&/=?-! MFRC7Q"MB![E.7;QB<\5#R*X7.^#K*-X,1I`3Z#QR:W:3HG4^08NR.N2YEXHG MH5^/JFPM"ZJAXBTU5)QEI;O2NSG$,:&BE=.G+[9'6)1+$!&X&.&5WK(N3%-9 MM]E0Z>78+(Q&6"T!\+ MMF?_'7RHL*DCC@_"V&S'.+LIBAA^T`'\UEI0B;6+%S';[ MH@YGYM]R8&TD5[IK*7$C@UA$@CLMP:NP20.;-/89EBS'4W%_J[C`=WAJ4-UF M1M@SKZ;,,U;"1C[JA.;XZ1-%#?B#$HL:WB<+]@PT[*$3F0W'VX_7';^L`G,` MFBO7`GKYJW=\OM8B6>)EVT#_1B:ILTQ7DWDU4XD]?O&[HH93;6^MTSD7T^(B M3)'@^CQ+S#38?WF6I]Q>,IF?@3"H9*U^8`,!R4@$U:IP%FB?@;`>F, MM*19S/QNL/)-W&1$ST5(18;*5FYTOI3Y70XDR2.;_DX4-2/!H$MG7LUQ9K;! M(?@%;$FYFC2@/'%0ZB5,]LAHD]^]CJ*2#(IP/6E=),1Q-*A<,'RY(%OOZ$V,_:F97Z<+=8QR(*$5/+3J M+<_"]=7@D;V>"45>?PPD^_I`S6-(F+CGGP6L+XL_9 M'YOYM3/S:^>2-OE;X'-Y'P[;FV/DJ,]@;*ZBN9`3`>_!`'R\[411FS)O.X;% MS+;M'Y+W.>7>\KX]0/1-QH16N?U3X$51FUAT3IGLE[-S(&=M>?(D!N6L#?$Q M`O^#8-MT@.)8:BZ*W)XE[^%-CZ);;(01Z92>N#8"0:?5 MR\GOH?<+]&_+C3L;P_#.QE&3MQVW5\%&N6D'IT0M=\.7/P3#DF-:.,BX<*[; M?L:N!NN97=\$X*5G^*5D["2KN^8_XTV*4%24^FT:_#;NG#]T`[I9];^OKB$XTO7K=_P+*7.M6;` M7.N4>#2^"3P-M-UD!H>%&0P4BR/,#'52)3:BRRNHTK5)U]4,.B-=_C-Z/PX4_K,UP8KDB2?\]0BP/V1F MB-OH*?,,4I$PZ2'SC#C''U[&RHR^J2+DMH:!J>@>!4["^V! M$PQF$]Y>--<<@=<7P5LWK0-6VZVS.\KX?'")@5,1#5D=*&-H2T(K3#'Q`DDK ME!S8DM"*'TQ@"_S5"6>-\3[8X(-W/[7`*GGX^D#RHR[A&['KAA)34[T.EEV^ M`C8S@XK,(?5P9K9#KS7DP8)"OOQW'=YIB9[1MTH-)S+;OPL0`K$OMT,8!N#E M*PJ*JEE5O<+*Z"+P=YN2#G#A8GU,=1Y!PK-+R0V2)V!'>B8KMI`A$XS*%KE" MAY>#0J>O#J5RU)\18&$)=\:)N>;H[R;9H1@HE`_=_AK6%^*V_PD;,$D%O^0' MC]G^]B#XKVK`O'-'(%[BM6FR6-_54MY+]%D\R77O)P`I_Q&WL"H3Q/KR'@(S M$5@(PIS_@O?'GGC8')W0"IM(.E+Q1GS.S!CW122U;`P^P9B_FZ^):3D1B3?; M!EMMB31WSN8*4DY!<8$$#1A[>A(PF!$-!H'`V,P"E<;^'[V8!<.=M,@D;8J0 MED0#E0Q+I4Q6W2J54TNVZ M.8!,TN)=]DS9B2:%VHH<^25F2&CXX*0CF_6?T>(1^VI(]$U._F`JB9;_CH,W M_H9,EL1'TK1M((O3"9MDBM/0;EL?O4E/3'DEZ$99*@9L!<@58+`1&FW62;0E M0Z3!+",_979.RFR2^',0#NR0^*-5`^3=3-[\*%$O;8H4:9L/VA-S9&0YHZ&< MT6HYSB4N:5.TDW?)`C1GF4-GUZ=0ZEXR1BL\H#MUR+<8E M9C(`7E&(^W7$PU4>$RYK:8O/Y\7@8FP';.4WE1JJ>L,;FP5/^)%N17.D=\H2 M9DHFU=74U2!>NVT)N!31QL2D"#(_`*EC>(EM0G#XRDIIBZ&)=# M!XO0D\$?_Q5=-[J)/,=']^+;;*2K8.-DEO*=>&`?UI`L>!4-1Q7C#:P)/,K- M[ZK&NO&F\DL4+![0KM%-:@QW43%CJ,W'19;7(@S6YIH;3ZIQ?/MH_^9,_.4; M(Q78"\LU+Y/EF@GJ;^'DY7RMZ)8M73`W\T'_S<4LWAY,>HUT+PZP,`,9+RUF MI`T&25?^@]9"4>]@M-5V6*LL($.[$NU-,VCY<>I0ON"/?B'+W8=S+V4:C-GE M/=]!5RMNWCD58O8A#GDJ)JLB"6[`Z)$KY?KEZ?3IBA5&.';P%5"I@8&(%RY** M1YT^-J.A2*GW@\K/4V2YKEG&'SL2&U:X899HZT[:K+6Y;B>+@]#88_*]D`-_ M:(P"@^M0#[-RV$Y<(2FL0V1^YX.8JLLL@O(;(.6%4E%:%R0!6SQUWR9,CVG0<& MUM`3$05O@$ZFEN7*Z(JQ.%-JI2`ICXEQQ27#"8&XY`>98IVMEH6IL.T2.Q17 MHH.O^KHFU'H-\M MHL0B9B7YR2=<:%8+`G7Q+7T"'=@Y!?M";X&3Q[Q7[&<^H[X)^@/^L0;$QUO+J^/C;1<8>Z8VFQMC7ZW)Y@SV)70VI[/S M5#;_<<$*7("6=U`C_]%#MPVJ_Q[SOXFTP3^L`_Y[^P4UI27=2-["JZ^I@-/7 M`LB[_O5D]&U0YX(?&D<0E,Z7"8)WOXG`&S'?+E[W<9&480!')\M;:%`Y=IH1!&S#47%6%$IJ%7,70$%BU?:*X=:7SCI7GOA M>GO<[6D1E6G:!%I#J!(Q!@Q415`4H\'XP9=H-&@-OD0#0C2^H(E"@M8O)!I3 M_#^[>Y)&&F/\@!\ZR?+KW?;:DKN9>7;FF5F3SP1AU*FK^-D$6<6=1R2DDAC) M:W,ZOY^D9;BDL(=L>GEVX%O)KCLVQ-\09[ZJ6")=^OZ>@,1*7D_>+S=+\:+P MAX.!GRYQJY!\V>E6 M9'[&WM!?.W!.]`8E#SS+.9J^X3L^CI;1\F^*81C_\!T=T>IRM[8:WCH""78D M1T%++"HC[U+M:25UJ;?>0`>05\C>-8J\?RV;GD]&V1V5'DI?X&Y"JK2L3ZA` MZ6(K<3K24FBI*I=*^BA6X>420N*5.`NKD36#^FH9&L4:;X-2/==;]Z"#6(OS MD$90RV:*"W$1UN%B#&,]-F`C-N%261N!MTH?B046XMZS3('M?2$7!"YHM*'\4O\"K_&;Z3EQR/2XB-]H_H1IA M7%G-Q"OP*I0;!\[&.7@-7HO7X?5X`\I,6`AK<3XN0&9^]$*\&>OP%@SC$FS` M"#9A%)?A;7@[WH%WXMVX'.]!Z1`MC&,;)G`E)C&%-J["##J8P_NP`^_'-?@@ M/F2XE5]W8A=V(SVY7F?(#(G2O3)AAQMP(_;AH[@)'\/-R`2K?@*WX%;D>E5O MPWY\"I_!';@3=^'SN!M?Q#V&O+%^42/$'J;Z'Y:J)L\2PYA07%A45%3`(J^Q MXXK'&2?S>S)[VR1[QQC?_U)TT?#'([?N!2.>S?\]?R]C_./TKRD\[9G1SII.5:+.;W%C&=B M[5:VPKV$N3%IQYQ$JK4J;2=2CIG-I=-VQC%3MF-RIL5J*1VO&D--B^K#H<7F M_/K(S.J;5)B35LK.M;:9[5:[G5EM.K892R;M%3'',N.)I&5FG4QNA9/+6%E> MGTC%52J6\O^?@_XZ"KGLO^Z[RKHIJJ![Z(=5AWL6R&8)?1>^]\;!6O<"6'5_\7C(KY_KWPWF MZWUE4)FS&N3C\4=(*O'QB#2ET67R[]!V-SRLE:_O[?\34$L!`A0`%`````@` MUR.V'LYVQ;?A!@``CC$```D````````````@`````````$9%05--+D]"2E!+ M`0(4`!0````(`-$CMAX2?L[-)!$``/\Z```)``````````$`(`````@'``!& M14%332Y!4TU02P$"%``4````"`#8([8>&U-9<+^````H^@``#``````````` K`"````!3&```159)3%5424\N15A%4$L%!@`````#``,`J````#R9```````` ` end sum -r/size 12184/54339 section (from "begin" to "end") sum -r/size 34109/39418 entire input file - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Mon May 22 14:07:51 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDehR-000fJIC; Mon, 22 May 95 14:07 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57118-1>; Mon, 22 May 1995 17:05:55 -0400 Date: Mon, 22 May 1995 17:05:36 -0400 From: Jeff Lait To: Martijn Faassen cc: AG Directors , ag-fe@alnilam.krl.caltech.edu Subject: Re: Universe > FE interface In-Reply-To: <199505222042.WAA13138@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 22 May 1995, Martijn Faassen wrote: > > Hi there, > > I was looking through/working on Universe code and a question came up. > > Currently as I see it two possible basic schemes for the Universe/FE > interface are possible: > > FE-driven: > IMHO, the FE should not have to worry about animation. It should draw with the current bitmap found in the object->picture (or whatever) field and should draw it at a size determined by object->size (of a number of fixed, predetermined sizes) with an inclination of object->angle. > > Universe-driven: > On the other hand, the Universe should have no part in drawing the objects. It should never say: DrawRotatedObject(x, y, object). Why? Because the order in how the objects are drawn, where and how they might be clipped, etc, must be platform independent. If we don't leave that to FE, a double buffered scheme would need a large number of static state variables to keep track of where it was at the last part. Also, SVGA systems may have their own concerns re: optimizing bank switching. (ie: run through all objects in first bank, then second, etc. picking up half way over ones on the final pass. This is a Good Thing if we're doing VESA where we need to drop down to real mode to change banks) So, having thrown out the universe & FE driven models, what's left :> What I propose is what I did in POC III, coming to a mailbox near you soon. Basically, the universe drives it's own routine saying `Move all ships, handle collisions, update which is the current picture/angle/whatever.' Then FE_RedrawScreen is invoked and is given a list of all objects which are likely to be on the screen (This list can be build during the Universe's phase). The FE then runs through this list drawing whatever it comes across. > The FE-driven scheme has the advantage that Universe doesn't have to care > so much about display oriented stuff, FE handles that mostly by itself. > The Universe-driven scheme has the advantage that we keep as much > FE independent code in Universe as possible. > And this has both advantages - though the list walking code could concievably be generic, I'd rather have the front end have control over the order of drawing. > Possibly the arrival of a generic FE group (so not architecture specific) > consisting of people in both Universe and the FE groups would alleviate > this problem. We currently have a generic FE group, namely ag-fe. I'd propose Universe can also be added to this list so we can all hash out the many and variagated concerns we have. > They could simply take care of the display engine, seperate > from Universe *and* the machine specific FE groups. Then again, it might > be more difficult for intergroup communication. I would propose said group would be for discussion only, ie: it produces no code. After all, its main raison d'etre is to determine the exact nature of the FE API. > Another option is of course what I'm doing now; going through the directors > group. > Trouble with this is that we are bothering those in A-Life to whom this is irrelevant & missing the members of Universe & FE groups. - Jeff Lait (SOL) From mcl.ucsb.edu!uwingcat Mon May 22 15:42:17 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDgAv-000fJ9C; Mon, 22 May 95 15:42 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id PAA24525 for ; Mon, 22 May 1995 15:40:36 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id PAA25364; Mon, 22 May 1995 15:40:36 -0700 Message-Id: <199505222240.PAA25364@mcl.mcl.ucsb.edu> Subject: Collision Detection To: ag-directors@krl.caltech.edu Date: Mon, 22 May 1995 15:40:36 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 458 Another idea: The universe.c file only checks a fixed-size bounding box (the box does not rotate with the sprite, although it does move with the sprite), and if two boxes overlap, calls FE_DetectCollision(object1,object2) for a more precise check using whatever algorithm works best w/the platform (circle-circle, bitmap-bitmap, etc.). The only thing that uiniverse.c sees is the returned result (1 or 0), and handles a collision if the result is 1. From undergrad.math.uwaterloo.ca!jmlait Mon May 22 17:19:09 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDhgW-000fJ9C; Mon, 22 May 95 17:18 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57187-2>; Mon, 22 May 1995 20:17:06 -0400 Date: Mon, 22 May 1995 20:17:00 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Re: Collision Detection In-Reply-To: <199505222240.PAA25364@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 22 May 1995, Adrian Tymes wrote: > Another idea: > > The universe.c file only checks a fixed-size bounding box (the box does not > rotate with the sprite, although it does move with the sprite), and if > two boxes overlap, calls FE_DetectCollision(object1,object2) for a more > precise check using whatever algorithm works best w/the platform > (circle-circle, bitmap-bitmap, etc.). The only thing that uiniverse.c > sees is the returned result (1 or 0), and handles a collision if the > result is 1. > This will work so long as the bounding box checked is larger than the width of the sprite at inclination 0. Ie: bounding box width = spritewidth * sqrt(2), assuming square sprites. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Mon May 22 17:36:38 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDhxb-000fJ9C; Mon, 22 May 95 17:36 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57189-3>; Mon, 22 May 1995 20:34:48 -0400 Date: Mon, 22 May 1995 20:34:42 -0400 From: Jeff Lait To: Adrian Tymes cc: FE-ALL , Directors Subject: Re: Universe Status Report & FE-PCX (fwd) In-Reply-To: <199505222250.PAA28236@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (I removed this from general as it isn't an announce oriented thread. It's on directors until we get some area for Universe/FE-ALL to bash it out :>) On Mon, 22 May 1995, Adrian Tymes wrote: > Nothing much happened on the universe group this week aside from a > continued discussion about bullets and eating. > > > Are we sure Universe won't be doing 16.16 fixed point??? If we > > end up with healthy frame rates, we could REALLY use the precision, the 2 > > bits of fraction which we'll have under the currently proposed system > > would probably result in some serious aliasing. > > The universe will be using integers with zero fraction bits. As for > precision, consider: > > 1 universe point < 1 pixel > > 1024 * 1024 universe points = 1 subsector < 1 screen > Woe... Last I had heard, 1 subsector >= 1 screen! Certainly not 11x11 per screen... I might have mentioned 11x11 tiles, but in that case we are definitely not talking subsectors. The whole point of subsectors (as I last heard) was to be able to look only though those objects which were close together for collision detection. It seems a bit extreme to then make them so small as to be able to fit only one ship inside each of them... > The last time that this issue was raised, the viewed area was set at a > 11 * 11 subsector square, so each subsector would be about 70 * 70 pixels > on a 1024 * 768 screen, since all of the subectors would be in a 768 * > 768 area. > > The precision comes from the conversion. > Granted, in this case one would get some precision: 35 x universe pixels would map to one x 320x200 pixel Not much, but some. Should I take these as the proper dimmensions? ie: the universe to fe converter will treat the viewing area as 1024*11x1024*11 universe pixels and construct a mapping of this onto the 320x200 screen? Are we to ignore aspect ratio though? Shouldn't the viewable area be 4:3? I've sent this also to FE-ALL as we need to get some of this settled (Apparently, some has been settled already, I'd just like to clarify what's left. I remember discussing a lot of this, but never seeing any conclusive decisions made) - Jeff Lait (SOL) From mcl.ucsb.edu!uwingcat Mon May 22 19:49:56 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDk2X-000fJ9C; Mon, 22 May 95 19:49 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id TAA13435 for ; Mon, 22 May 1995 19:48:10 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id TAA24939; Mon, 22 May 1995 19:48:11 -0700 Message-Id: <199505230248.TAA24939@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report & FE-PCX (fwd) To: ag-directors@krl.caltech.edu Date: Mon, 22 May 1995 19:48:11 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3105 > (I removed this from general as it isn't an announce oriented thread. > It's on directors until we get some area for Universe/FE-ALL to bash it > out :>) Good move. > > > Are we sure Universe won't be doing 16.16 fixed point??? If we > > > end up with healthy frame rates, we could REALLY use the precision, the 2 > > > bits of fraction which we'll have under the currently proposed system > > > would probably result in some serious aliasing. > > > > The universe will be using integers with zero fraction bits. As for > > precision, consider: > > > > 1 universe point < 1 pixel > > > > 1024 * 1024 universe points = 1 subsector < 1 screen > > > Woe... Last I had heard, 1 subsector >= 1 screen! Certainly not > 11x11 per screen... I might have mentioned 11x11 tiles, but in that case > we are definitely not talking subsectors. The whole point of subsectors > (as I last heard) was to be able to look only though those objects which > were close together for collision detection. It seems a bit extreme to > then make them so small as to be able to fit only one ship inside each > of them... When did you hear this? 1 subsector has always been less than 1 screen. The original plan was 3*3 subsectors per screen. And there may be much more than one ship per subsector, but due to code limits in universe.c, no ship can be larger than 1 subsector. Since FE limits ships to no more than 1/11th of the screen by 1/11th of the screen, we decided to make these two limits equal. > > The last time that this issue was raised, the viewed area was set at a > > 11 * 11 subsector square, so each subsector would be about 70 * 70 pixels > > on a 1024 * 768 screen, since all of the subectors would be in a 768 * > > 768 area. > > > > The precision comes from the conversion. > > > Granted, in this case one would get some precision: 35 x universe > pixels would map to one x 320x200 pixel Not much, but some. Is that too little precision? > Should I take these as the proper dimmensions? ie: the universe > to fe converter will treat the viewing area as 1024*11x1024*11 universe > pixels and construct a mapping of this onto the 320x200 screen? Are we > to ignore aspect ratio though? Shouldn't the viewable area be 4:3? The FE routine should map the subsector that the player is in, and all subsectors with x and y numbers (= universe coords * 1024) +/- up to 5. Those sectors are the ones that might be seen and will be drawn; the picture will be centered on the player, so a part of some of the subsectors will be cut out. As for the 4:3 ratio, only a 3:3 area will contain the subsectors. The remaining 1:3 will be used for status reports. Didn't I send this info to this group two weeks ago? > I've sent this also to FE-ALL as we need to get some of this > settled (Apparently, some has been settled already, I'd just like to > clarify what's left. I remember discussing a lot of this, but never > seeing any conclusive decisions made) I didn't see the address for the fe-all group. What is it, so I can forward my part of this discussion to it? From mcl.ucsb.edu!uwingcat Mon May 22 19:52:44 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDk5K-000fJ9C; Mon, 22 May 95 19:52 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id TAA13600 for ; Mon, 22 May 1995 19:51:04 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id TAA25513; Mon, 22 May 1995 19:51:04 -0700 Message-Id: <199505230251.TAA25513@mcl.mcl.ucsb.edu> Subject: Re: Collision Detection (fwd) To: ag-directors@krl.caltech.edu Date: Mon, 22 May 1995 19:51:04 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 875 > > Another idea: > > > > The universe.c file only checks a fixed-size bounding box (the box does not > > rotate with the sprite, although it does move with the sprite), and if > > two boxes overlap, calls FE_DetectCollision(object1,object2) for a more > > precise check using whatever algorithm works best w/the platform > > (circle-circle, bitmap-bitmap, etc.). The only thing that uiniverse.c > > sees is the returned result (1 or 0), and handles a collision if the > > result is 1. > > > This will work so long as the bounding box checked is larger > than the width of the sprite at inclination 0. Ie: bounding box width = > spritewidth * sqrt(2), assuming square sprites. It is a prerequisite on all objects that their bounding box be large enough to fully cover the entire object at any inclination. (FE: you are going to check that this is so, right?) From mcl.ucsb.edu!uwingcat Mon May 22 21:23:15 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDlUp-000fJIC; Mon, 22 May 95 21:23 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id VAA17759 for ; Mon, 22 May 1995 21:21:26 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id VAA11675; Mon, 22 May 1995 21:21:26 -0700 Message-Id: <199505230421.VAA11675@mcl.mcl.ucsb.edu> Subject: Re: Collision Detection (fwd) To: ag-directors@krl.caltech.edu Date: Mon, 22 May 1995 21:21:26 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 280 > It is a prerequisite on all objects that their bounding box be large enough > to fully cover the entire object at any inclination. > > (FE: you are going to check that this is so, right?) Oops...I meant to address this last comment to the AI directors, not the FE directors. From undergrad.math.uwaterloo.ca!jmlait Tue May 23 06:21:12 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDttU-000fJ9C; Tue, 23 May 95 06:21 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56960-3>; Tue, 23 May 1995 09:19:22 -0400 Date: Tue, 23 May 1995 09:19:18 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, FE-ALL Subject: Re: Universe Status Report & FE-PCX (fwd) In-Reply-To: <199505230248.TAA24939@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 22 May 1995, Adrian Tymes wrote: > > (I removed this from general as it isn't an announce oriented thread. > > It's on directors until we get some area for Universe/FE-ALL to bash it > > out :>) > > Good move. > FE-ALL is ag-fe@krl... It seems it was stripped from your header, but as I didn't recieve an address not found I presume it was sent all right... > > Woe... Last I had heard, 1 subsector >= 1 screen! Certainly not > > 11x11 per screen... I might have mentioned 11x11 tiles, but in that case > > we are definitely not talking subsectors. The whole point of subsectors > > (as I last heard) was to be able to look only though those objects which > > were close together for collision detection. It seems a bit extreme to > > then make them so small as to be able to fit only one ship inside each > > of them... > > When did you hear this? 1 subsector has always been less than 1 screen. > The original plan was 3*3 subsectors per screen. And there may be much more > than one ship per subsector, but due to code limits in universe.c, no ship > can be larger than 1 subsector. Since FE limits ships to no more than > 1/11th of the screen by 1/11th of the screen, we decided to make these two > limits equal. Way back when, around POC I, there were 64x64 subsectors to the toroidial universe, and each subsector was 1024x1024 which was mapped to the screen. Ie: 1 subsector = 1 screen. However, that has since been changed. As I said, I remember this being discussed - but I don't recall us coming to any conclusions (Discussion appeared to dry up....). Anyways, doesn't matter overmuch to FE-PCX, so long as we can find what objects to draw. Just seems that you'd have a lot more special case code of having to deal with objects hitting the bounds of their subsectors, but as I said, that's your problem, not mine :> > > > The last time that this issue was raised, the viewed area was set at a > > > 11 * 11 subsector square, so each subsector would be about 70 * 70 pixels > > > on a 1024 * 768 screen, since all of the subectors would be in a 768 * > > > 768 area. > > > > > > The precision comes from the conversion. > > > > > Granted, in this case one would get some precision: 35 x universe > > pixels would map to one x 320x200 pixel Not much, but some. > > Is that too little precision? > Probably it's enough. I just like to be on the safe side because from where I am standing I don't see where you'd get a performance penalty from doing 16.16. We'll try it and see how it works. To give you an example, the former there would give you 2 pixels error per second when running at 70fps, at 640x480 it would be 4 (Mind you, I don't see us running at 70fps there :>) My biggest concern is that it limits the accuracy of slow movement & of angles. > > Should I take these as the proper dimmensions? ie: the universe > > to fe converter will treat the viewing area as 1024*11x1024*11 universe > > pixels and construct a mapping of this onto the 320x200 screen? Are we > > to ignore aspect ratio though? Shouldn't the viewable area be 4:3? > > The FE routine should map the subsector that the player is in, and > all subsectors with x and y numbers (= universe coords * 1024) +/- up to 5. > Those sectors are the ones that might be seen and will be drawn; the picture > will be centered on the player, so a part of some of the subsectors will be > cut out. > Okay... So does the FE get a pointer to the array of subsectors, each which is some linked list of objects to draw? Where is the current universe.c code anyways so I can fix up POC 3 to use it... > As for the 4:3 ratio, only a 3:3 area will contain the subsectors. The > remaining 1:3 will be used for status reports. > > Didn't I send this info to this group two weeks ago? > As I said, you did mention that you wanted 1:1 aspect when I brought up aspect ratio, but I certainly didn't agree with you :> In FE-PCX we'll probably have on screen windows to handle status reports, menus, etc.. I don't see why we (the end users) should lose 1/4 of our screen to status reports! - Jeff Lait (SOL) From charles Tue May 23 07:06:20 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDubB-000fJ9C; Tue, 23 May 95 07:06 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA20852; Tue, 23 May 1995 07:05:07 -0700 Message-Id: <9505231405.AA20852@altair.krl.caltech.edu> Subject: Re: Universe Status Report & FE-PCX To: ag-directors Date: Tue, 23 May 1995 07:05:06 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 739 -- By: Jeff Lait > On Mon, 22 May 1995, Adrian Tymes wrote: > > > > (I removed this from general as it isn't an announce oriented thread. > > > It's on directors until we get some area for Universe/FE-ALL to bash it > > > out :>) > > > > Good move. > > > FE-ALL is ag-fe@krl... > It seems it was stripped from your header, but as I didn't > recieve an address not found I presume it was sent all right... ag-fe@krl.caltech.edu *does* exits. Currently it contains only the GE groups, but I'll add in universe if thats what people want. Unfortunately as an artifact of one list bounceing the mail to the others, all of the other lists archive the messages, so I didn't bother archiving the ag-fe list seperately. --- Charles From mcl.ucsb.edu!uwingcat Tue May 23 11:05:06 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDyKB-000fJMC; Tue, 23 May 95 11:04 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id LAA17284; Tue, 23 May 1995 11:03:18 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id LAA10883; Tue, 23 May 1995 11:03:16 -0700 Message-Id: <199505231803.LAA10883@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report & FE-PCX (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 23 May 1995 11:03:15 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3407 > FE-ALL is ag-fe@krl... *This* message should be forwarded to ag-fe...would anyone who gets this message and is not on the directors list care to confirm that you're getting it? > Anyways, doesn't matter overmuch to FE-PCX, so long as we can > find what objects to draw. Just seems that you'd have a lot more special > case code of having to deal with objects hitting the bounds of their > subsectors, but as I said, that's your problem, not mine :> It has already been coded (as UN_Shift()...I don't think that anyone else will want to use this, but I can release the header if anyone else will use it). Just a simple "remove object from one linked list and insert into another" routine. > > Is that too little precision? > > > Probably it's enough. I just like to be on the safe side because > from where I am standing I don't see where you'd get a performance > penalty from doing 16.16. We'll try it and see how it works. Well, x and y *are* signed long ints, so we already use 17 bits...maybe FE could interpret it as 16.16, and ignore everything except the sign to the left of the point? > To give you an example, the former there would give you 2 pixels > error per second when running at 70fps, at 640x480 it would be 4 (Mind > you, I don't see us running at 70fps there :>) My biggest concern is > that it limits the accuracy of slow movement & of angles. Angles are an entirely seperate issue (256 degrees), aren't they? Slow movement can go to an accuracy of < 1/2 pixel, which should be more than enough if we do bitmap collision detection, which has an inherent accuracy of 1 pixel. > Okay... So does the FE get a pointer to the array of subsectors, > each which is some linked list of objects to draw? Where is the current > universe.c code anyways so I can fix up POC 3 to use it... There are global arrays: object *objects[MAXOBJECTS]; object *sector[64][64]; objects[0] always points to the current player probe...when the player switches probes (voluntarily or involuntarily), the new probe is swapped to objects[0] from wherever else in the array it was. To get the 11 * 11 subsectors surrounding the player: X=((objects[0]->x)/1024)%64; Y=((objects[0]->y)/1024)%64; CenterScreen((objects[0]->x)%(64*1024),(objects[0]->y)%(64*1024)); for (i=X-5;i<=X+5;i++) for (j=Y-5;i<=Y+5;j++) DrawSub(i,j); /* with appropriate modulo 64 calculations for i and j if X and Y are near 0 or 63 */ Of course, if you want the universe.c code to have different dimensions (for instance, 256 * 256 subsectors w/4096 * 4096 universe points per subsector), please specify the dimensions that you would like. Just as long as (SUBSECTORS*POINTSPERSUB) <= 2 ** 31 , with both SUBSECTORS and POINTSPERSUB being powers of 2, and the x dimensions equal to to y dimensions. We'd only have to change a few variables, actually. > As I said, you did mention that you wanted 1:1 aspect when I > brought up aspect ratio, but I certainly didn't agree with you :> In > FE-PCX we'll probably have on screen windows to handle status reports, > menus, etc.. I don't see why we (the end users) should lose 1/4 of our > screen to status reports! To keep the player's viewed area consistent with the probes' viewed area. To avoid "cheating" by the probes, we are making the probes' interface as equal to the player's as possible (thus their "virtual keyboards"). From undergrad.math.uwaterloo.ca!jmlait Tue May 23 12:01:19 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDzCc-000fJMC; Tue, 23 May 95 12:01 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56998-1>; Tue, 23 May 1995 14:59:27 -0400 Date: Tue, 23 May 1995 14:59:11 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Universe Status Report & FE-PCX (fwd) In-Reply-To: <199505231803.LAA10883@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 23 May 1995, Adrian Tymes wrote: > > > > Is that too little precision? > > > > > Probably it's enough. I just like to be on the safe side because > > from where I am standing I don't see where you'd get a performance > > penalty from doing 16.16. We'll try it and see how it works. > > Well, x and y *are* signed long ints, so we already use 17 bits...maybe > FE could interpret it as 16.16, and ignore everything except the sign to > the left of the point? > Why are x/y signed? After all, what meaning does a negative x or y value mean? Why not just do them as unsigned 16.16? > > To give you an example, the former there would give you 2 pixels > > error per second when running at 70fps, at 640x480 it would be 4 (Mind > > you, I don't see us running at 70fps there :>) My biggest concern is > > that it limits the accuracy of slow movement & of angles. > > Angles are an entirely seperate issue (256 degrees), aren't they? > Ahh, but when dx & dy are calculated through a lookup on the sine/cosine table, it is dependent upon the accuracy of x/y! Ie: if the angle's dx/dy values get rounded to zero, the resulting movement would be missing a component. For example, if inclination = 1, sin(1) is small. If it is smaller than the resolution allowed by Universe code, the component generated by sin(x) would disappear from calculations & the ship will move in a straight line, not at a 1 degree angle. > Slow movement can go to an accuracy of < 1/2 pixel, which should be more > than enough if we do bitmap collision detection, which has an inherent > accuracy of 1 pixel. > I'm thinking again about the components. Each component has an accuracy of 1/35 of a pixel, which mean when moving at 32 degrees (45 in traditional system) your total speed is accurate to what, 1/20 th of a pixel? This error rapidly becomes non-zero when accumulated over multiple frames. Again, it probably won't have a serious impact, but I'd rather have 16.16 installed now than try and add it later. > > Okay... So does the FE get a pointer to the array of subsectors, > > each which is some linked list of objects to draw? Where is the current > > universe.c code anyways so I can fix up POC 3 to use it... > > There are global arrays: > > object *objects[MAXOBJECTS]; > object *sector[64][64]; > Okay, I thought we had agreed a long time ago that having an array of objects was pointless, as it limitted the number of objects for no readily seeable benefit????? Sector is fine... Though I would suggest making the subsectors larger, ie: more like 4x3 per screen than 11x11. Remember each time an object is moved to another subsector is a non-zero length of time to move it (This obviously has to be balanced against the fact that larger sectors mean more collision detection, and more non needed inbounds checking. Also, larger sector size means a larger playing field (So long as 64x64 is used) - 11x11 makes a playing field 6x6 screens, 4x3 would give you 16x21) The final decision re: this is independent of FE so don't feel pressured on any aspect except aspect ratio. > objects[0] always points to the current player probe...when the player > switches probes (voluntarily or involuntarily), the new probe is swapped > to objects[0] from wherever else in the array it was. > Again, FE doesn't care - just pass it an object which is to be used as the object to centre the screen at. > To get the 11 * 11 subsectors surrounding the player: > > X=((objects[0]->x)/1024)%64; > Y=((objects[0]->y)/1024)%64; > > CenterScreen((objects[0]->x)%(64*1024),(objects[0]->y)%(64*1024)); > > for (i=X-5;i<=X+5;i++) for (j=Y-5;i<=Y+5;j++) DrawSub(i,j); > /* with appropriate modulo 64 calculations for i and j if X and Y are > near 0 or 63 */ > The majority of those calculations are not required in the current format. The original reason why I came up with the arbitrary dimmensions of 64x64 and 1024x1024 in POC 1 was for the sake of creating a torroidial space with no need for special code to handle the edges. In other words, if x/y are unsigned longs, with the upper 16bits denoting the position, and lower 16 the fraction, calculations become simpler: ; Upon movement: cur->x += UN_cos(cur->angle) * cur->speed * time; cur->y += UN_sin(cur->angle) * cur->speed * time; I understand you will have dx/dy values precalculated, in which case the trig function & speed are replaced by cur->dx/dy. This leaves a multiplication of a fixed by a scalar - no probs. Time, is. of course, the time since the last frame in some convinent base: how about milliseconds? As you see - there is no need to worry about doing any fixed point conversion nor handling torroidal space. ; Your example: Getting the appropriate subsectors: cX = you->X >> (16 + 10); cY = you->Y >> (16 + 10); for (i = -5; i <= 5; i++) { for (j=-5;j<=5;j++) { DoSub(sectors[(i+cX)&63][(j+cy)&63]; | } Should suffice, barring me reversing x/y :> > Of course, if you want the universe.c code to have different dimensions > (for instance, 256 * 256 subsectors w/4096 * 4096 universe points per > subsector), please specify the dimensions that you would like. Just as > long as (SUBSECTORS*POINTSPERSUB) <= 2 ** 31 , with both SUBSECTORS and > POINTSPERSUB being powers of 2, and the x dimensions equal to to y > dimensions. We'd only have to change a few variables, actually. > I think the current settings are perfect. Namely for the fact that with 16.16 they fit perfectly within a long. > > As I said, you did mention that you wanted 1:1 aspect when I > > brought up aspect ratio, but I certainly didn't agree with you :> In > > FE-PCX we'll probably have on screen windows to handle status reports, > > menus, etc.. I don't see why we (the end users) should lose 1/4 of our > > screen to status reports! > > To keep the player's viewed area consistent with the probes' viewed > area. To avoid "cheating" by the probes, we are making the probes' > interface as equal to the player's as possible (thus their "virtual > keyboards"). > Which is all fine. So why not either: A) Give the probes a 4:3 viewing area (or 12:9) B) Give the human the minor advantage of a slightly larger viewing area. I don't think many avid game players would welcome the idea of a reduced viewscreen. 'Specially considerign the fact we hardly need to reduce it for speed reasons: Alife would run just as fast and FE-PCX at least would hardly feel the change. BTW: Have you seen POC III and got a chance to look at it? What do you think of the current implementation of FE_IsKey? Is this the sort of virtual keyboard (on the FE-end) which was discussed a while ago? - Jeff Lait (SOL) P.S. Is anyone else reading this willing to comment on aspect ratio? Am I the only one who believes the game should run full screen? From phil.ruu.nl!faassen Tue May 23 12:03:29 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sDzEj-000fJOC; Tue, 23 May 95 12:03 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id VAA12476 for ; Tue, 23 May 1995 21:01:43 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id VAA23357 for ag-directors@alnilam.krl.caltech.edu; Tue, 23 May 1995 21:01:35 +0200 From: Martijn Faassen Message-Id: <199505231901.VAA23357@laurel.stud.phil.ruu.nl> Subject: Re: Collision Detection (fwd) To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 23 May 1995 21:01:31 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 622 > > It is a prerequisite on all objects that their bounding box be large enough > > to fully cover the entire object at any inclination. > > > > (FE: you are going to check that this is so, right?) > > Oops...I meant to address this last comment to the AI directors, not the > FE directors. Now I don't understand it anymore. :) What does AI got to do with collision detection? Or are you referring to eating upon collision, and so on? Even in that case, we'll be using the Universe collision detection code, whatever it'll be? Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From charles Tue May 23 17:41:45 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sE4W0-000fJRC; Tue, 23 May 95 17:41 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA01802; Tue, 23 May 1995 17:42:07 -0700 Message-Id: <9505240042.AA01802@altair.krl.caltech.edu> Subject: Pictures! To: ag-directors, ag-art-sound Date: Tue, 23 May 1995 17:42:07 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 296 Greetings, I just realized what we need most to make the web-site really readable by outsiders is pictures. Is anyone particularly interested in drawing or otherwise creating some interesting ones? Also, I think we should start making plans for the Great Recruitment... :-) --- Charles From undergrad.math.uwaterloo.ca!jmlait Tue May 23 18:10:44 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sE4y9-000fJSC; Tue, 23 May 95 18:10 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57105-1>; Tue, 23 May 1995 21:10:39 -0400 Date: Tue, 23 May 1995 21:10:38 -0400 From: Jeff Lait To: Directors Subject: POC III Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've send POC 3 to the upload directory of ftp.krl.etc. Is this the proper place to put it now? - Jeff Lait (SOL) From wam.umd.edu!keithw Tue May 23 20:20:16 1995 Return-Path: Received: from pg2-srv.wam.umd.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sE6is-000fJRC; Tue, 23 May 95 20:03 PDT Received: from rac10.wam.umd.edu (keithw@rac10.wam.umd.edu [128.8.70.125]) by pg2-srv.wam.umd.edu (8.6.10/8.6.9) with ESMTP id WAA07706; Tue, 23 May 1995 22:14:23 -0400 Received: (keithw@localhost) by rac10.wam.umd.edu (8.6.10/8.6.10) id WAA11445; Tue, 23 May 1995 22:14:22 -0400 Date: Tue, 23 May 1995 22:14:21 -0400 (EDT) From: Keith Wiley To: Splinterwood cc: ag-directors@krl.caltech.edu, ag-art-sound@krl.caltech.edu Subject: Re: Pictures! In-Reply-To: <9505240042.AA01802@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Greetings, > > I just realized what we need most to make the web-site really > readable by outsiders is pictures. Is anyone particularly interested > in drawing or otherwise creating some interesting ones? Also, I think > we should start making plans for the Great Recruitment... :-) I'm something of an amateur computer artist (check out my web page. I did all the graphics). I'll see if I can come up with some scenic stuff. . . .. ... ..... ........ ............. ..................... .. ... ..... ....... ........... ............. ................. . .. .... ........ ................ ................................ Keith Wiley, Electrogenetic Engineer * University of Maryland at College Park * * * * * * email: keithw@wam.umd.edu *** ** * * ** * world wide web: http://www.wam.umd.edu/~keithw * ** ** *** From post.demon.co.uk!darkin.demon.co.uk!Christian Wed May 24 09:15:34 1995 Return-Path: <@post.demon.co.uk:Christian@darkin.demon.co.uk> Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEJ5i-000fJRC; Wed, 24 May 95 09:15 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id aa17077; 24 May 95 17:13 +0100 Received: from darkin.demon.co.uk by post.demon.co.uk id aa19729; 24 May 95 17:13 +0100 Date: Wed, 24 May 1995 08:46:21 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <197@darkin.demon.co.uk> To: ag-directors@alnilam.krl.caltech.edu Subject: Re: Pictures! X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 29 In your message dated Tuesday 23, May 1995 you wrote : > Greetings, > > I just realized what we need most to make the web-site really > readable by outsiders is pictures. Is anyone particularly interested > in drawing or otherwise creating some interesting ones? Also, I think > we should start making plans for the Great Recruitment... :-) > The web-site looks good. As for the great recruitment, how about a page at the web-site detailing exactly who we need once we've worked out who we need :) Have we started plugging the web-site on the newsgroups yet? Maybe that's the next step now it's up and running. > --- Charles > > -- Christian Darkin From charles Wed May 24 09:31:07 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEJKq-000fJUC; Wed, 24 May 95 09:31 PDT Sender: charles (Charles Ofria) Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA00967; Wed, 24 May 1995 09:31:27 -0700 Message-Id: <9505241631.AA00967@rigel.krl.caltech.edu> Subject: Re: Pictures! To: Christian@darkin.demon.co.uk Date: Wed, 24 May 1995 09:31:12 -0800 (PDT) From: "Splinterwood" In-Reply-To: <197@darkin.demon.co.uk> from "Christian Darkin" at May 24, 95 08:46:21 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 653 Sender: charles > The web-site looks good. Thanx. I try. :-) > As for the great recruitment, how about a page at the > web-site detailing exactly who we need once we've worked out who we need :) Sounds good. If everyone sends me the type of people they need, I'll compose the page. > Have we started plugging the web-site on the newsgroups yet? > Maybe that's the next step now it's up and running. Thats definately a soon step. Two things I'd like to do first; Get a couple of pictures up to make the site more appealing, and get the archives on the site so that the more industrius people can find out what they've been missing. :-) --- Charles From mcl.ucsb.edu!uwingcat Wed May 24 13:52:18 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sENPb-000fJKC; Wed, 24 May 95 13:52 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id NAA07381 for ; Wed, 24 May 1995 13:52:10 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id NAA06092; Wed, 24 May 1995 13:52:06 -0700 Message-Id: <199505242052.NAA06092@mcl.mcl.ucsb.edu> Subject: Re: Collision Detection (fwd) To: ag-directors@krl.caltech.edu Date: Wed, 24 May 1995 13:52:06 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 771 > > > It is a prerequisite on all objects that their bounding box be large enough > > > to fully cover the entire object at any inclination. > > > > > > (FE: you are going to check that this is so, right?) > > > > Oops...I meant to address this last comment to the AI directors, not the > > FE directors. > > Now I don't understand it anymore. :) What does AI got to do with > collision detection? Or are you referring to eating upon collision, and > so on? Even in that case, we'll be using the Universe collision detection > code, whatever it'll be? AI has much (almost everything) to do with object generation...after all, the routine to create any type of object (even an asteroid) is AI_CreateObject(), is it not? This is one of the bounds on that routine. From phil.ruu.nl!faassen Wed May 24 15:17:00 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEOjZ-000fJ9C; Wed, 24 May 95 15:16 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id AAA14913 for ; Thu, 25 May 1995 00:16:53 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id AAA19959 for ag-directors@alnilam.krl.caltech.edu; Thu, 25 May 1995 00:16:47 +0200 From: Martijn Faassen Message-Id: <199505242216.AAA19959@laurel.stud.phil.ruu.nl> Subject: AI & object creation To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 25 May 1995 00:16:46 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1800 > > Now I don't understand it anymore. :) What does AI got to do with > > collision detection? Or are you referring to eating upon collision, and > > so on? Even in that case, we'll be using the Universe collision detection > > code, whatever it'll be? > > AI has much (almost everything) to do with object generation...after all, > the routine to create any type of object (even an asteroid) is > AI_CreateObject(), is it not? This is one of the bounds on that routine. What? You mean AI will be creating bullet objects? Asteroid objects too? But that has nothing whatsoever to do with AI? We're only supplying behaviour and evolution. We'll only let behave and evolve things that Universe supplies us with. Even egg objects can be created by Universe, as long as AI knows about them being there, so we can mix the parents (and we'll only need to know about it *after* fertilisation, not even when it's laid.. because only then we'll know who the parents are. Same with probes: Universe knows (hears from Alife, probably) when an egg is ready to hatch. Then Universe creates a probe object. Alife will set the properties determined by evolution in it, and then signals 'ready' to Universe, which does the hatching bit, and throws the object in the object list, so it'll be processed by Universe from now on. Why should the alife group ever have to know specific front end/Universe information about an object? The only thing alife has to know, possibly, is the size of an object (big boss probe or normal probe, and if we do evolving bullets, maybe that too), not bbox size. Anyway, obviously some misunderstandings arose here, so let's keep this discussion going. Hoping for more opinions on this, Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From mcl.ucsb.edu!uwingcat Wed May 24 15:57:02 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEPMI-000fJ9C; Wed, 24 May 95 15:56 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id PAA05504 for ; Wed, 24 May 1995 15:56:57 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id PAA19386; Wed, 24 May 1995 15:56:54 -0700 Message-Id: <199505242256.PAA19386@mcl.mcl.ucsb.edu> Subject: AI & object creation (fwd) To: ag-directors@krl.caltech.edu Date: Wed, 24 May 1995 15:56:53 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2647 > What? You mean AI will be creating bullet objects? Asteroid objects too? Good thing we hit this landmine before calls to AI_CreateObject() were written! > But that has nothing whatsoever to do with AI? We're only supplying behaviour > and evolution. We'll only let behave and evolve things that Universe > supplies us with. You're also determining the probes' initial physical aspects. AI evolution code has total control over that aspect...the only things that it doesn't control are the objects' initial position and velocity, and even those can be specified relative to certain other objects. > Even egg objects can be created by Universe, as long as > AI knows about them being there, so we can mix the parents (and we'll only > need to know about it *after* fertilisation, not even when it's laid.. > because only then we'll know who the parents are. Yeah, but what if you decide to handle variable numbers of parents? And how does the universe know when the egg should hatch? Or what the nutritional value of an egg that's been eaten by a specific probe is? Maybe we should merge & spilt the UN and AI code as follows: UN: Handles all processes that involve more than one object (collisions, game tree, syskeys, etc.) AL: Handles all processes that involve one object physically affecting itself (including whatever happens to eggs that have just been fertilized) and/or creating another object, and passes the relevant flags to UN when one object tries to affect another object in object-specific ways (grabbing, eating, fertilizing, etc.). AI: Handles all behavioral aspects of the probes. While this code may look at any data that the programmers want it to, its only output will be the probes' virtual keyboards...this does not affect anything directly. The only exception is that there will be an AI routine to create new AI code given old AI code that AL calls when a new probe hatches. This should rather clearly delineate what does what...we may want to create a new mailing list for AL, or bounce AL stuff to both alife and the universe group (as is currently being done by double-forwarding) similar to the ag-fe list's function. Comments? > Why should the alife group ever have to know specific front end/Universe > information about an object? The only thing alife has to know, possibly, > is the size of an object (big boss probe or normal probe, and if we do > evolving bullets, maybe that too), not bbox size. Bbox size is evolved, as is the probe's bitmap. Starting positions are specified relative to creators' positions, if applicable. What other universe/front end info is there? From phil.ruu.nl!faassen Wed May 24 17:50:22 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sER7u-000fJ9C; Wed, 24 May 95 17:50 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id CAA18195 for ; Thu, 25 May 1995 02:50:11 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id CAA21502 for ag-directors@alnilam.krl.caltech.edu; Thu, 25 May 1995 02:50:04 +0200 From: Martijn Faassen Message-Id: <199505250050.CAA21502@laurel.stud.phil.ruu.nl> Subject: Re: AI & Object creation To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 25 May 1995 02:50:02 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9696 > > What? You mean AI will be creating bullet objects? Asteroid objects too? > > Good thing we hit this landmine before calls to AI_CreateObject() were > written! Agreed. :) > > But that has nothing whatsoever to do with AI? We're only supplying behaviour > > and evolution. We'll only let behave and evolve things that Universe > > supplies us with. > > You're also determining the probes' initial physical aspects. AI evolution > code has total control over that aspect...the only things that it doesn't > control are the objects' initial position and velocity, and even those > can be specified relative to certain other objects. Well.. > > Even egg objects can be created by Universe, as long as > > AI knows about them being there, so we can mix the parents (and we'll only > > need to know about it *after* fertilisation, not even when it's laid.. > > because only then we'll know who the parents are. > > Yeah, but what if you decide to handle variable numbers of parents? This wouldn't be hard. Currently we want different probes to be able to donate energy to an egg. We can keep a list of 'energy donators' in each egg. If we ever decide to go for multiple parents, we can use this structure easily, with only very minor changes to Universe. (Universe would keep the list, as donating energy is a purely universe action) > And > how does the universe know when the egg should hatch? Or what the > nutritional value of an egg that's been eaten by a specific probe is? Nutritional value would be simply based on energy content of an egg (as currently I'm planning investment points total also to be based on energy content). Energy content is determined by parents investing, and possible other benefactors. Nutritional value is then a purely Universe property. As it should be, I think? (so that if we decide to throw out/ change/whatever nutritional value completely later, alife won't know more than - some different virtual keys (if those are changed by the eating change) - some other properties to examine in objects (instead of the nutritional value prop). > Maybe we should merge & spilt the UN and AI code as follows: > > UN: Handles all processes that involve more than one object (collisions, > game tree, syskeys, etc.) > > AL: Handles all processes that involve one object physically affecting > itself (including whatever happens to eggs that have just been > fertilized) and/or creating another object, and passes the relevant flags > to UN when one object tries to affect another object in object-specific ways > (grabbing, eating, fertilizing, etc.). > AI: Handles all behavioral aspects of the probes. While this code may > look at any data that the programmers want it to, its only output will be > the probes' virtual keyboards...this does not affect anything directly. > The only exception is that there will be an AI routine to create new AI > code given old AI code that AL calls when a new probe hatches. I was thinking of a different split: UN: Handles objects. Some objects (probe, player) are controlled by virtual keypresses. A virtual keypress is associated with an action. The action will be handled by Universe as much as possible. The only exceptions would be: - when an egg has been fertilized and is (after some preset time by Universe?) ready for hatching, alife (which includes AI btw) needs to be warned. Alife will look in the egg, see pointer to the parents, and will look up the genetic info of the parents. This genetic info falls apart in two things: - physical - behaviourial Physical properties of an object are all implemented by Universe. Alife will (communicating with Universe about this) assign investment point costs to each property. (and to how much of that property you get, for example shield strength may be a shield point <-> investment point conversion of some kind). These costs will probably need to be tweaked a lot during playtesting. (example, if we have a linear conversion of investment for shield it may be a strategy to invest virtually everything in shield, which will then maybe become unbreakable for a long long time, leaving the probe free to do other things..or whatever..that's why we need playtesting :). Alife will create routines which combine the investment point distributions of the two parents into a new investment plan for the hatching probe. Then another alife routine will turn the investment plan into real properties, stored in the unviverse accessible part of the probe. This routine will use the energy content of the egg to determine how much investment points are available. Then, the object will be initialised for Universe, so alife will set this egg to 'hatch'. Universe will read that next time it passes by the egg, and the egg will be replaced by the newborn probe. (pointer to newborn probe is available for egg). Universe performs inclusion in sectors, and so on. Recap for physical: Alife: gets warned when egg is ready, combines investment plans of parents into new plan, uses new plan and investment points based on energy of egg to generate actual values, and then creates a new probe object with those values. Note that all this includes the weapon investment of the probe. This is simply part of the same procedure. Stores pointer of new probe in egg and sets egg to hatch. (if behaviour part is also ready) Universe: Puts pointers to parents and benefactors in a list of the egg, maintains energy in egg, nutritional value of egg which is mostly based on energy (+ some constant). Maintains age of egg and fertilisation status. If egg is fertilized and has a certain age, Alife is warned, which will do the combining. (this might be so fast it is ready next tick, or we may want to spread it out across ticks (more complicated). If egg is set to hatch, then look in egg for a pointer to the probe that's hatching. Insert the probe in the object list, insert it in sector and do the Universe thing with probes. :) Now, the behaviour part of egg hatching is very similar to this, instead of investment plans behaviour code is combined by the alife part. Alife would like to have a signal back from universe as soon as the probe is put in the universe (after the hatching), to know when to start the behaviour code associated to that probe. Hmm.. any other exceptions.. Well, weaponry is simply a subcase of the general investment stuff. Alife will have nothing to do with weapons after their properties have been set, except, when, later, we'll have 'remote controlled' weapons. (we'll try branching off part of the behaviour code in each probe to control their remote controlled objects - basically the same principle as in controlling the probes themselves). Alife/AI does not handle: asteroids bullet creation & other weapon stuff eating, picking up, dropping, and so on If we want to 'seed probes' (something we probably should only implement if it turns out to be necessary..it probably will, but we don't know yet), we'll have to have another interface between alife and universe. Basically Universe would handle the where and how many, and Alife will handle which probes are being seeded, probably grabbing them from a list of prepared probes for this. (which alife would need to keep then, but we can add all that later). > This should rather clearly delineate what does what...we may want to > create a new mailing list for AL, or bounce AL stuff to both alife and > the universe group (as is currently being done by double-forwarding) > similar to the ag-fe list's function. A new mailing list would be too much. The physical part can be fairly separated from the behaviourial part of alife, yes, but I think we can handle both (the physical part when Universe comes up with a list of evolvable properties in objects, including weaponry). Perhaps a special bouncing setup instead of the double forwarding would be good, though. (this would then be dedicated to the physical properties discussions). Or maybe keep the properties discussion to Universe for a while. If we start bouncing I'll get mail a lot of times, as I'm on both groups. :) > Comments? Why, yeah, lots? Comments to this? :) > > Why should the alife group ever have to know specific front end/Universe > > information about an object? The only thing alife has to know, possibly, > > is the size of an object (big boss probe or normal probe, and if we do > > evolving bullets, maybe that too), not bbox size. > > Bbox size is evolved, as is the probe's bitmap. Starting positions are > specified relative to creators' positions, if applicable. What other > universe/front end info is there? > But I thought FE had only a few fixed bitmap sizes? So Bbox size wouldn't vary much? Currently I didn't see probe size as an evolvable property. Instead it can be related to how many investment points a probe got from parents and possible benefactors. If it got really little, it'll be small, then there's normal, and if it got really much, it'll be big (boss). This could be seen as a way to compensate: if you got less energy invested you'll have less shields and weapons, but you'll be small, harder to hit and low mass so more acceleration. If however you got lots of investment, you'll be big, easier to hit, and you'll have to move a large mass. So, in this case: no, it wouldn't be evolved, but, yes, alife would handle sizeclasses. (what the actual bbsizes will be, we'll delegate to Universe). Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From phil.ruu.nl!faassen Wed May 24 18:12:02 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sERSx-000fJ9C; Wed, 24 May 95 18:11 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id DAA18470 for ; Thu, 25 May 1995 03:11:56 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id DAA21911 for ag-directors@alnilam.krl.caltech.edu; Thu, 25 May 1995 03:11:50 +0200 From: Martijn Faassen Message-Id: <199505250111.DAA21911@laurel.stud.phil.ruu.nl> Subject: Permission Denied when trying to FTP To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 25 May 1995 03:11:48 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 292 I'm frustrated. I'm trying to ftp poc3.zip from /pub/alife-game/program, at ftp.krl.caltech.edu, but I'm getting 'access denied' when I try to 'get' the file, when using Fetch on the mac, and also when using 'ftp' under Unix, so it's a pretty general problem.. Can this be fixed? Martijn From mcl.ucsb.edu!uwingcat Wed May 24 20:38:21 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sETkQ-000fJ9C; Wed, 24 May 95 20:38 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id UAA25838; Wed, 24 May 1995 20:38:07 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id UAA00885; Wed, 24 May 1995 20:38:04 -0700 Message-Id: <199505250338.UAA00885@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report & FE-PCX (fwd) To: ag-directors@krl.caltech.edu Date: Wed, 24 May 1995 20:38:03 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 8298 > > Well, x and y *are* signed long ints, so we already use 17 bits...maybe > > FE could interpret it as 16.16, and ignore everything except the sign to > > the left of the point? > > > Why are x/y signed? After all, what meaning does a negative x or > y value mean? Why not just do them as unsigned 16.16? Oops...I was thinking of velx and vely. x and y are unsigned, of course. > > > To give you an example, the former there would give you 2 pixels > > > error per second when running at 70fps, at 640x480 it would be 4 (Mind > > > you, I don't see us running at 70fps there :>) My biggest concern is > > > that it limits the accuracy of slow movement & of angles. > > > > Angles are an entirely seperate issue (256 degrees), aren't they? > > > Ahh, but when dx & dy are calculated through a lookup on the > sine/cosine table, it is dependent upon the accuracy of x/y! Ie: if the > angle's dx/dy values get rounded to zero, the resulting movement would be > missing a component. For example, if inclination = 1, sin(1) is small. > If it is smaller than the resolution allowed by Universe code, the > component generated by sin(x) would disappear from calculations & the > ship will move in a straight line, not at a 1 degree angle. sin(360/256)= approx. 1/40 , so a speed of 40 universe points per frame would be the cutoff between one-axis and two-axis movement at 1 of our degrees. Since 1024 universe points = about 70 pixels, a speed of 40 = (40*70)/1024 = 2800/1024 = approx. 3 pixels per frame...you're right, we should go for greater accuracy. At least 4K points per subsector, probably at least 16K. > > Slow movement can go to an accuracy of < 1/2 pixel, which should be more > > than enough if we do bitmap collision detection, which has an inherent > > accuracy of 1 pixel. > > > I'm thinking again about the components. Each component has an > accuracy of 1/35 of a pixel, which mean when moving at 32 degrees (45 in > traditional system) your total speed is accurate to what, 1/20 th of a > pixel? This error rapidly becomes non-zero when accumulated over > multiple frames. Again, it probably won't have a serious impact, but I'd > rather have 16.16 installed now than try and add it later. And as calculated above, there are more serious accuracy problems... > > > Okay... So does the FE get a pointer to the array of subsectors, > > > each which is some linked list of objects to draw? Where is the current > > > universe.c code anyways so I can fix up POC 3 to use it... > > > > There are global arrays: > > > > object *objects[MAXOBJECTS]; > > object *sector[64][64]; > > > Okay, I thought we had agreed a long time ago that having an > array of objects was pointless, as it limitted the number of objects for > no readily seeable benefit????? Readily seeable benefit: No during-action malloc() calls...malloc() is, to my knowledge, slow on almost all compilers, maybe all compilers. > Sector is fine... Though I would suggest making the subsectors > larger, ie: more like 4x3 per screen than 11x11. Remember each time an > object is moved to another subsector is a non-zero length of time to move > it (This obviously has to be balanced against the fact that larger > sectors mean more collision detection, and more non needed inbounds > checking. Also, larger sector size means a larger playing field (So long > as 64x64 is used) - 11x11 makes a playing field 6x6 screens, 4x3 would > give you 16x21) The final decision re: this is independent of FE so > don't feel pressured on any aspect except aspect ratio. Like I said, 1:1 is for AI's benefit, to make the player's interface as similar to the probes' as possible. If you want more than 64*64 sectors, sure, why not? > > objects[0] always points to the current player probe...when the player > > switches probes (voluntarily or involuntarily), the new probe is swapped > > to objects[0] from wherever else in the array it was. > > > Again, FE doesn't care - just pass it an object which is to be > used as the object to centre the screen at. > > > To get the 11 * 11 subsectors surrounding the player: > > > > X=((objects[0]->x)/1024)%64; > > Y=((objects[0]->y)/1024)%64; > > > > CenterScreen((objects[0]->x)%(64*1024),(objects[0]->y)%(64*1024)); > > > > for (i=X-5;i<=X+5;i++) for (j=Y-5;i<=Y+5;j++) DrawSub(i,j); > > /* with appropriate modulo 64 calculations for i and j if X and Y are > > near 0 or 63 */ > > > > The majority of those calculations are not required in the > current format. The original reason why I came up with the arbitrary > dimmensions of 64x64 and 1024x1024 in POC 1 was for the sake of creating > a torroidial space with no need for special code to handle the edges. In > other words, if x/y are unsigned longs, with the upper 16bits denoting > the position, and lower 16 the fraction, calculations become simpler: > > ; Upon movement: > cur->x += UN_cos(cur->angle) * cur->speed * time; > cur->y += UN_sin(cur->angle) * cur->speed * time; > I understand you will have dx/dy values precalculated, in which > case the trig function & speed are replaced by cur->dx/dy. This leaves a > multiplication of a fixed by a scalar - no probs. Actually, this is the current code: if (object thrusts) { cur->velx += (cur->thrust * cos(cur->angle))/cur->mass; cur->vely += (cur->thrust * sin(cur->angle))/cur->mass; } /* we may drop the mass division if AI incorporates that into its thrust variable, although mass itself will stay for collision resolution */ cur->x += cur->velx; cur->y += cur->vely; > Time, is. of course, the time since the last frame in some > convinent base: how about milliseconds? Every object is updated every frame. Time is a constant, and its multiply is unnecessary. > As you see - there is no need to worry about doing any fixed > point conversion nor handling torroidal space. > > ; Your example: Getting the appropriate subsectors: > cX = you->X >> (16 + 10); > cY = you->Y >> (16 + 10); > > for (i = -5; i <= 5; i++) { > for (j=-5;j<=5;j++) { > DoSub(sectors[(i+cX)&63][(j+cy)&63]; > | > } > Should suffice, barring me reversing x/y :> Optimise away...I was just providing the functional code description. > > Of course, if you want the universe.c code to have different dimensions > > (for instance, 256 * 256 subsectors w/4096 * 4096 universe points per > > subsector), please specify the dimensions that you would like. Just as > > long as (SUBSECTORS*POINTSPERSUB) <= 2 ** 31 , with both SUBSECTORS and > > POINTSPERSUB being powers of 2, and the x dimensions equal to to y > > dimensions. We'd only have to change a few variables, actually. > > > I think the current settings are perfect. Namely for the fact > that with 16.16 they fit perfectly within a long. As I typed above, we'll probably want to increase it. > > > As I said, you did mention that you wanted 1:1 aspect when I > > > brought up aspect ratio, but I certainly didn't agree with you :> In > > > FE-PCX we'll probably have on screen windows to handle status reports, > > > menus, etc.. I don't see why we (the end users) should lose 1/4 of our > > > screen to status reports! > > > > To keep the player's viewed area consistent with the probes' viewed > > area. To avoid "cheating" by the probes, we are making the probes' > > interface as equal to the player's as possible (thus their "virtual > > keyboards"). > > > Which is all fine. So why not either: > A) Give the probes a 4:3 viewing area (or 12:9) AI had objections to this, I forget what they were... > B) Give the human the minor advantage of a slightly larger > viewing area. > I don't think many avid game players would welcome the idea of a > reduced viewscreen. 'Specially considerign the fact we hardly need to > reduce it for speed reasons: Alife would run just as fast and FE-PCX at > least would hardly feel the change. > > BTW: Have you seen POC III and got a chance to look at it? What > do you think of the current implementation of FE_IsKey? Is this the sort > of virtual keyboard (on the FE-end) which was discussed a while ago? I haven't had a chance to look at POC III yet (maybe over the weekend); I've had a lot of schoolwork to do this past week. From undergrad.math.uwaterloo.ca!jmlait Wed May 24 20:59:43 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEU5E-000fJ9C; Wed, 24 May 95 20:59 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57216-2>; Wed, 24 May 1995 23:59:26 -0400 Date: Wed, 24 May 1995 23:59:17 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Finite number of object sizes...?? In-Reply-To: <199505242256.PAA19386@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > Why should the alife group ever have to know specific front end/Universe > > information about an object? The only thing alife has to know, possibly, > > is the size of an object (big boss probe or normal probe, and if we do > > evolving bullets, maybe that too), not bbox size. > > Bbox size is evolved, as is the probe's bitmap. Starting positions are > specified relative to creators' positions, if applicable. What other > universe/front end info is there? > Une question, SVP! How variable is the bounding box? Is the FE-PCX's request of only having a limited number of different sized objects, and having all bullets symmetrical, accepted? It would be a performance hit if it is not - we're all ready running at 10-13 cycles/pixel (depending upon whether pixel is clear). The inner loop would stay the same, but the outer loop would have a LOT more overhead. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed May 24 21:05:44 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEUB3-000fJ9C; Wed, 24 May 95 21:05 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57181-1>; Thu, 25 May 1995 00:05:32 -0400 Date: Thu, 25 May 1995 00:05:30 -0400 From: Jeff Lait To: Martijn Faassen cc: AG Directors Subject: Re: AI & Object creation In-Reply-To: <199505250050.CAA21502@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > - when an egg has been fertilized and is (after some preset time by Universe?) > ready for hatching, alife (which includes AI btw) needs to be warned. > Alife will look in the egg, see pointer to the parents, and will > look up the genetic info of the parents. This genetic info falls apart in > two things: - physical > - behaviourial One question: What if the parents are dead? Is Universe to keep a copy of dead ships around who still have eggs waiting to be hatched? Shouldn't the genetic code of the egg be determined at laying/fertilization to ensure the parents are still viable? > Well, weaponry is simply a subcase of the general investment stuff. Alife > will have nothing to do with weapons after their properties have been set, > except, when, later, we'll have 'remote controlled' weapons. (we'll try > branching off part of the behaviour code in each probe to control > their remote controlled objects - basically the same principle as in > controlling the probes themselves). Well, I see the FE groups have their work cut out to keep this real time :> > But I thought FE had only a few fixed bitmap sizes? So Bbox size wouldn't > vary much? Currently I didn't see probe size as an evolvable property. I hope this is the case :> - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed May 24 21:28:44 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEUXJ-000fJ9C; Wed, 24 May 95 21:28 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57241-2>; Thu, 25 May 1995 00:28:28 -0400 Date: Thu, 25 May 1995 00:28:25 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Universe Status Report & FE-PCX (fwd) In-Reply-To: <199505250338.UAA00885@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 24 May 1995, Adrian Tymes wrote: > Oops...I was thinking of velx and vely. x and y are unsigned, of course. > Well, a similar arguement holds for velx & vely - though they are signed, you will only get overflow if they go faster than 2^16 pixels/frame. Ie: never :> > > Ahh, but when dx & dy are calculated through a lookup on the > > sine/cosine table, it is dependent upon the accuracy of x/y! Ie: if the > > angle's dx/dy values get rounded to zero, the resulting movement would be > > missing a component. For example, if inclination = 1, sin(1) is small. > > If it is smaller than the resolution allowed by Universe code, the > > component generated by sin(x) would disappear from calculations & the > > ship will move in a straight line, not at a 1 degree angle. > > sin(360/256)= approx. 1/40 , so a speed of 40 universe points per frame > would be the cutoff between one-axis and two-axis movement at 1 of our > degrees. Since 1024 universe points = about 70 pixels, a speed of 40 = > (40*70)/1024 = 2800/1024 = approx. 3 pixels per frame...you're right, we > should go for greater accuracy. At least 4K points per subsector, > probably at least 16K. > Or, you could do fixed point. Presto. Problem solved, leave it at 1k points per subsector (A perfectly reasonable choice) and 64x64 sectors. That's my vote - fixes precision problems & ensures that we don't have 256 visible ship orientations but only 16 flight directions :> > > > There are global arrays: > > > > > > object *objects[MAXOBJECTS]; > > > object *sector[64][64]; > > > > > Okay, I thought we had agreed a long time ago that having an > > array of objects was pointless, as it limitted the number of objects for > > no readily seeable benefit????? > > Readily seeable benefit: No during-action malloc() calls...malloc() is, > to my knowledge, slow on almost all compilers, maybe all compilers. > If you think this is a problem (Which I don't) make a linked list of object heaps & a linked list of disposed objects. New heap allocation is a bit slower than equivalent malloc, but later so long as the disposed heap is non empty one has little problems. Big problem with this is that you can't free memory - as soon as a heap is allocated, it is pretty much in memory until you quit, start a new game, or run a (slow!) compression on it. What do I mean by heaps? struct HEAP_NODE { OBJECT objects[OBJ_PER_HEAP]; ; Probably 256 or so. HEAP_NODE *next; }; HEAP_NODE *object_heap = NULL; OBJECT *disposed_list = NULL; The objects have a *nxtdisposed field added, so the heap alloc looks like this: OBJECT *AllocNewObj() { HEAP_NODE *temp; int i1; OBJECT *ret; if (!disposed_list) { // No free objects, create heap! temp = (HEAP_NODE *) malloc(sizeof(HEAP_NODE)); if (!temp) CompactHeaps(); temp->next = object_heap; object_heap = temp; for (i1 = 0; i1 < OBJ_PER_HEAP; i1++) { object_heap->objects[i1].nxtdisposed = disposed_list; disposed_list = &object_heap->objects[i1]; } } ret = disposed_list; disposed_list = disposed_list->next; return(ret); } void FreeObj(OBJECT *delete) { delete->next = diposed_list; disposed_list = delete; } void FreeHeaps() { HEAP_NODE *cur; for (cur = object_heap; cur; cur = cur->next) { free(cur); } } Probably a couple minor errors there... Anyways, this is only really necessary if you feel that mallocs are too slow, or are allocating very small objects which would take up too much space if allocated via malloc (I think under Windoze minimum alloc is 4096bytes.) > Like I said, 1:1 is for AI's benefit, to make the player's interface as > similar to the probes' as possible. If you want more than 64*64 sectors, > sure, why not? > I don't want more than 64x64 sectors. I like the 64x64/1024x1024/16bit fixed point method. > Actually, this is the current code: > > if (object thrusts) > { cur->velx += (cur->thrust * cos(cur->angle))/cur->mass; > cur->vely += (cur->thrust * sin(cur->angle))/cur->mass; } > > /* we may drop the mass division if AI incorporates that into its thrust > variable, although mass itself will stay for collision resolution */ > > cur->x += cur->velx; > cur->y += cur->vely; > > > > Time, is. of course, the time since the last frame in some > > convinent base: how about milliseconds? > > Every object is updated every frame. Time is a constant, and its multiply > is unnecessary. Whoa... That assumes a constant frame rate, not only between computers, but between frames! Each object must take into account the time since the last frame, not the number of frames. If we do this right, the user, upon hitting the turbo button part way through the game, will only notice a change in smoothness (Actually, that would probably screw any music, but if we're running grfx alone it should just get chunkier with the turbo off.) Remember, when you're fighting in a swamr of aliens, firing bullets wildly, the frame rate will likely drop from when you are cruising interstellar space... > > I think the current settings are perfect. Namely for the fact > > that with 16.16 they fit perfectly within a long. > > As I typed above, we'll probably want to increase it. But is not the reason why you wish to increase it because of precision? So why not just leave it as it is and add the 16bits of precision to the end? > > Which is all fine. So why not either: > > A) Give the probes a 4:3 viewing area (or 12:9) > > AI had objections to this, I forget what they were... > That's fine... Do option B then. > > B) Give the human the minor advantage of a slightly larger > > viewing area. - Jeff Lait (SOL) From charles Thu May 25 07:03:21 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEdVN-000fJKC; Thu, 25 May 95 07:03 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA12072; Thu, 25 May 1995 07:03:44 -0700 Message-Id: <9505251403.AA12072@altair.krl.caltech.edu> Subject: Re: AI & Object creation To: ag-directors Date: Thu, 25 May 1995 07:03:44 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2033 > One question: What if the parents are dead? Is Universe to keep > a copy of dead ships around who still have eggs waiting to be hatched? > Shouldn't the genetic code of the egg be determined at > laying/fertilization to ensure the parents are still viable? I suspect that *most* eggs which get laid will never reach the hatching point; it would probably be cheaper to keep track of the partents genome after they die then keeping track of hundreds of egg genomes. We should certainly at least wait until fertilization before we start putting info in. Think of it this way; if we don't create the genome until fertilization then sometimes we will have to keep the mothers genome after she dies, but if we had put it in there already we would have had to be storing two copies all along, and once she dies, we're back to where we started from. If we wait until hatching for the new creatures genome, then we're in a similar state where we only waste memory if *both* parents die; if either one dies its just as expensive to keep a single genome around as to have made it already. Now, it seems to me that if both parents are going to die its not very likely for an egg to get to a hatching point.... > > Well, weaponry is simply a subcase of the general investment stuff. Alife > > will have nothing to do with weapons after their properties have been set, > > except, when, later, we'll have 'remote controlled' weapons. (we'll try > > branching off part of the behaviour code in each probe to control > > their remote controlled objects - basically the same principle as in > > controlling the probes themselves). > > Well, I see the FE groups have their work cut out to keep this > real time :> Perhaps we should set things up so the user can configure what parts can and can't evolve with warnings that things might slip out of real-time if too many of these parts are turned on. Wow - and then they can get to play a different game (effectivly) every time just by changing what can be evolved. --- Charles From firga.sun.ac.za!9515291 Thu May 25 13:16:19 1995 Return-Path: <9515291@firga.sun.ac.za> Received: from oliver.sun.ac.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEjKE-000fJ2C; Thu, 25 May 95 13:16 PDT Received: from styx.sun.ac.za by oliver.sun.ac.za with smtp (Smail3.1.29.0 #2) id m0sEiu7-001587C; Thu, 25 May 95 21:49 EET Received: From SUN_FIRGA/WORKQUEUE by styx.sun.ac.za via Charon-4.0A-VROOM with IPX id 100.950525215016.480; 25 May 95 21:50:03 -0200 Message-ID: From: "G-J van Rooyen" <9515291@firga.sun.ac.za> Organization: University of Stellenbosch To: ag-directors@krl.caltech.edu Date: Thu, 25 May 1995 21:50:10 GMT+200 Subject: Re: Collision Detection Priority: normal X-mailer: Pegasus Mail v3.22 It's been very quiet from my side - I apologize, I'm a bit swamped with work at the moment, and semester exams are looming in the (too) near future. :( On Mon, 22 May 1995, Jeff Lait wrote: > What I propose is to equip the ships with > shields. Perfectly circular shields :> When a shield is hit, it glows > and then fades away again. Colour of the glow could very well depend on > the strength. This way all collision detection just needs to be done > against a circle of R = W/sqrt(2), where W=H=width=height. Excellent idea. It'll definitely make life much easier, and should be a pleasing enough visual effect. Collision with asteroids is no problem, as they are approximately round anyway, and the same goes for eggs. Cheers G-J +-------------------------------------------------+ | 9515291@firga.sun.ac.za (Gert-Jan van Rooyen) | | University of Stellenbosch | | South Africa | +-------------------------------------------------+ From mcl.ucsb.edu!uwingcat Thu May 25 17:56:38 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEnhV-000fJ2C; Thu, 25 May 95 17:56 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id RAA28880; Thu, 25 May 1995 17:56:22 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id RAA28667; Thu, 25 May 1995 17:56:25 -0700 Message-Id: <199505260056.RAA28667@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report & FE-PCX (fwd) To: ag-directors@krl.caltech.edu Date: Thu, 25 May 1995 17:56:25 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6418 > > Oops...I was thinking of velx and vely. x and y are unsigned, of course. > > > Well, a similar arguement holds for velx & vely - though they are > signed, you will only get overflow if they go faster than 2^16 > pixels/frame. Ie: never :> Well, technically a probe could get its "thrust" button stuck and never turn, but it would probably bash itself to bits before it got to that high a speed. BTW, we were discussing relativity or absolute speed limits...would you say that we need either? > > > Ahh, but when dx & dy are calculated through a lookup on the > > > sine/cosine table, it is dependent upon the accuracy of x/y! Ie: if the > > > angle's dx/dy values get rounded to zero, the resulting movement would be > > > missing a component. For example, if inclination = 1, sin(1) is small. > > > If it is smaller than the resolution allowed by Universe code, the > > > component generated by sin(x) would disappear from calculations & the > > > ship will move in a straight line, not at a 1 degree angle. > > > > sin(360/256)= approx. 1/40 , so a speed of 40 universe points per frame > > would be the cutoff between one-axis and two-axis movement at 1 of our > > degrees. Since 1024 universe points = about 70 pixels, a speed of 40 = > > (40*70)/1024 = 2800/1024 = approx. 3 pixels per frame...you're right, we > > should go for greater accuracy. At least 4K points per subsector, > > probably at least 16K. > > > Or, you could do fixed point. Presto. Problem solved, leave it > at 1k points per subsector (A perfectly reasonable choice) and 64x64 > sectors. That's my vote - fixes precision problems & ensures that we > don't have 256 visible ship orientations but only 16 flight directions :> How does fixed point change this? If the stuff to the right of the point is the in-subsector position, and to the left is the subsector number, the problem remains. If the stuff to the left is the in-subsector position, then where do we store the subsector number? > > > > There are global arrays: > > > > > > > > object *objects[MAXOBJECTS]; > > > > object *sector[64][64]; > > > > > > > Okay, I thought we had agreed a long time ago that having an > > > array of objects was pointless, as it limitted the number of objects for > > > no readily seeable benefit????? > > > > Readily seeable benefit: No during-action malloc() calls...malloc() is, > > to my knowledge, slow on almost all compilers, maybe all compilers. > > > If you think this is a problem (Which I don't) make a linked list > of object heaps & a linked list of disposed objects. New heap allocation > is a bit slower than equivalent malloc, but later so long as the disposed > heap is non empty one has little problems. Big problem with this is that > you can't free memory - as soon as a heap is allocated, it is pretty much > in memory until you quit, start a new game, or run a (slow!) compression > on it. Big problem is right: so what happens when we max out memory in mid-game? Slow compressions during the game would stop the action arbitrarily. > Probably a couple minor errors there... Anyways, this is only > really necessary if you feel that mallocs are too slow, or are allocating > very small objects which would take up too much space if allocated via > malloc (I think under Windoze minimum alloc is 4096bytes.) Probably the largest elements will be the AS ones (and *what are they*, anyway? We *are* recoding the object structure definition...) If those are over 4096 bytes, we're safe. If they're significantly under 4096 bytes, we're probably in trouble if we code for Windows. And this isn't the problem. The problem *is* that I think that in-game mallocs tend to be too slow (based on my personal experience with coding games). > > > Time, is. of course, the time since the last frame in some > > > convinent base: how about milliseconds? > > > > Every object is updated every frame. Time is a constant, and its multiply > > is unnecessary. > > Whoa... That assumes a constant frame rate, not only between > computers, but between frames! Each object must take into account the > time since the last frame, not the number of frames. We already have code that ensures a constant frame per CPU cycle ratio. It is FE's responsibility to ensure a constant frame per time ratio between computers, if desired. > If we do this > right, the user, upon hitting the turbo button part way through the game, > will only notice a change in smoothness (Actually, that would probably > screw any music, but if we're running grfx alone it should just get > chunkier with the turbo off.) Here's the relevant code, cut from a while(1) loop: /* set loop variables */ for (curobj=0;curobj0) UN_UpdateObject(object[curobj]); if (objects[0]->curarm<=0) { AS_PlayFX(FX_DIE); if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } /* UN_NewLife() returns 1 if no lives left for the player */ while (ticksper>FE_GetTicks(lasticks)) AI_DoQueue(lasticks); lasticks=FE_Update(); /* check for syskeys and victory conditions */ FE_Update() and FE_GetTicks() are expected to adjust their returned values if the user presses the turbo button in mid-game, if we want to let the user do that. > Remember, when you're fighting in a swamr of aliens, firing > bullets wildly, the frame rate will likely drop from when you are > cruising interstellar space... Actually, no. Not the way that we're implementing it, anyway... > > > I think the current settings are perfect. Namely for the fact > > > that with 16.16 they fit perfectly within a long. > > > > As I typed above, we'll probably want to increase it. > > But is not the reason why you wish to increase it because of > precision? So why not just leave it as it is and add the 16bits of > precision to the end? Because the x and y variables store the subsector number *AND* the position within the subsector. Maybe we should make it 8.24 fixed point? > > > Which is all fine. So why not either: > > > A) Give the probes a 4:3 viewing area (or 12:9) > > > > AI had objections to this, I forget what they were... > > > That's fine... Do option B then. AI objected to that because we were trying to make the human's and probes' interfaces equal. > > > B) Give the human the minor advantage of a slightly larger > > > viewing area. From mcl.ucsb.edu!uwingcat Thu May 25 18:00:29 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEnlK-000fJ3C; Thu, 25 May 95 18:00 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id SAA29530 for ; Thu, 25 May 1995 18:00:18 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id SAA29546; Thu, 25 May 1995 18:00:22 -0700 Message-Id: <199505260100.SAA29546@mcl.mcl.ucsb.edu> Subject: Bounding Box size To: ag-directors@alnilam.krl.caltech.edu Date: Thu, 25 May 1995 18:00:22 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 189 For now, why don't we just define a single bounding-box/sprite size for all objects, and later add in the possibility of choosing from a predefined list of sprite and bounding box sizes? From undergrad.math.uwaterloo.ca!jmlait Fri May 26 06:17:51 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sEzGt-000fJ2C; Fri, 26 May 95 06:17 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56892-1>; Fri, 26 May 1995 09:17:32 -0400 Date: Fri, 26 May 1995 09:17:28 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Universe Status Report & FE-PCX (fwd) In-Reply-To: <199505260056.RAA28667@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 25 May 1995, Adrian Tymes wrote: > > > Oops...I was thinking of velx and vely. x and y are unsigned, of course. > > > > > Well, a similar arguement holds for velx & vely - though they are > > signed, you will only get overflow if they go faster than 2^16 > > pixels/frame. Ie: never :> > > Well, technically a probe could get its "thrust" button stuck and never > turn, but it would probably bash itself to bits before it got to that high > a speed. BTW, we were discussing relativity or absolute speed > limits...would you say that we need either? > Good point. I'd say just throw a maximum velocity in casuaully, no need to do anything as fancy as relativity, just have the ships hit a maximum velocity, if it is high enough, the users won't notice in normal play but prevent probes from discovering that flying at high speed make the imune to enemy shots :> > > > > Ahh, but when dx & dy are calculated through a lookup on the > > > > sine/cosine table, it is dependent upon the accuracy of x/y! Ie: if the > > > > angle's dx/dy values get rounded to zero, the resulting movement would be > > > > missing a component. For example, if inclination = 1, sin(1) is small. > > > > If it is smaller than the resolution allowed by Universe code, the > > > > component generated by sin(x) would disappear from calculations & the > > > > ship will move in a straight line, not at a 1 degree angle. > > > > > > sin(360/256)= approx. 1/40 , so a speed of 40 universe points per frame > > > would be the cutoff between one-axis and two-axis movement at 1 of our > > > degrees. Since 1024 universe points = about 70 pixels, a speed of 40 = > > > (40*70)/1024 = 2800/1024 = approx. 3 pixels per frame...you're right, we > > > should go for greater accuracy. At least 4K points per subsector, > > > probably at least 16K. > > > > > Or, you could do fixed point. Presto. Problem solved, leave it > > at 1k points per subsector (A perfectly reasonable choice) and 64x64 > > sectors. That's my vote - fixes precision problems & ensures that we > > don't have 256 visible ship orientations but only 16 flight directions :> > > How does fixed point change this? If the stuff to the right of the point is > the in-subsector position, and to the left is the subsector number, the > problem remains. If the stuff to the left is the in-subsector position, then > where do we store the subsector number? > ?? The way I proposed was to store it as: 33222222222211111111110000000000 10987654321098765432109876543210 | || || | | | +------------ Fractional subsector position. | +----------------------- Integral subsector position. +------------------------------- Subsector #. Thus, we can have movement rates with 16 binary points in them. How does this not solve the precision problem??? > > If you think this is a problem (Which I don't) make a linked list > > of object heaps & a linked list of disposed objects. New heap allocation > > is a bit slower than equivalent malloc, but later so long as the disposed > > heap is non empty one has little problems. Big problem with this is that > > you can't free memory - as soon as a heap is allocated, it is pretty much > > in memory until you quit, start a new game, or run a (slow!) compression > > on it. > > Big problem is right: so what happens when we max out memory in > mid-game? Slow compressions during the game would stop the action > arbitrarily. On the other hand, compare this to suddenly being unable to fire part way through the game Remember, the number of heaps allocated will never be more than MAXOBJECT/HEAP_SIZE, where MAXOBJECT is the maximum number of objects ever apearing in the game. Sure the user might get a momentary glitch, but this would occur only if they are short on RAM in the first place (I don't see a 16meg machine ever having to do this). Presumably, you will still have MaxShips at which point you stop creating ships, but we should never stop creating bullets/whatever. Also, this allows us to run with less memory on machines with little memory, as we can set MaxShips at runtime, possibly at the users request. > > Probably a couple minor errors there... Anyways, this is only > > really necessary if you feel that mallocs are too slow, or are allocating > > very small objects which would take up too much space if allocated via > > malloc (I think under Windoze minimum alloc is 4096bytes.) > > And this isn't the problem. The problem *is* that I think that in-game > mallocs tend to be too slow (based on my personal experience with coding > games). Then do a heap method. I don't see how it's worse than an array, but do see how it is better in many ways. (Incidentally, didn't the original array have an array of POINTERS to objects? Which means one would need to allocate them anyways??? Probably a typo, no?, as it doesn't seem inline with what you've been saying....) > > Whoa... That assumes a constant frame rate, not only between > > computers, but between frames! Each object must take into account the > > time since the last frame, not the number of frames. > > We already have code that ensures a constant frame per CPU cycle ratio. > It is FE's responsibility to ensure a constant frame per time ratio > between computers, if desired. Hey... We aren't miracle workers here. The speed of frames WILL change during game time if more objects are to be drawn and/or the user changes detail levels. > > If we do this > > right, the user, upon hitting the turbo button part way through the game, > > will only notice a change in smoothness (Actually, that would probably > > screw any music, but if we're running grfx alone it should just get > > chunkier with the turbo off.) > > Here's the relevant code, cut from a while(1) loop: > > /* set loop variables */ > for (curobj=0;curobj if (object[curobj].life>0) UN_UpdateObject(object[curobj]); > if (objects[0]->curarm<=0) { AS_PlayFX(FX_DIE); > if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } > /* UN_NewLife() returns 1 if no lives left for the player */ > while (ticksper>FE_GetTicks(lasticks)) AI_DoQueue(lasticks); > lasticks=FE_Update(); > /* check for syskeys and victory conditions */ > > FE_Update() and FE_GetTicks() are expected to adjust their returned > values if the user presses the turbo button in mid-game, if we want to > let the user do that. > What is ticksper? How is it determined? And most importantly, what if FE takes longer than ticksper? And if it does, and ticksper is then increased, what if FE takes less time than is expected? This appears to assume that FE_Update() will always take constant time, something we cannot guarantee. That is why I suggested time should be included - it removes all these worries at a very small expense. > > Remember, when you're fighting in a swamr of aliens, firing > > bullets wildly, the frame rate will likely drop from when you are > > cruising interstellar space... > > Actually, no. Not the way that we're implementing it, anyway... > So what do we do, not draw half the bullets??? > > But is not the reason why you wish to increase it because of > > precision? So why not just leave it as it is and add the 16bits of > > precision to the end? > > Because the x and y variables store the subsector number *AND* the position > within the subsector. Maybe we should make it 8.24 fixed point? > Again, I'm failing to see something here. Yes, the x&y variables DO store those two things, but 16.16, with the top 16 storing those two things, would solve the precision problem, no? > > > > Which is all fine. So why not either: > > > > A) Give the probes a 4:3 viewing area (or 12:9) > > > > > > AI had objections to this, I forget what they were... > > > > > That's fine... Do option B then. > > AI objected to that because we were trying to make the human's and > probes' interfaces equal. > Sheesh, either give the probes or the player the advantage I say. Realism is all cool and all, but a lot of people would throw away realism if that's the only way you can play full screen. (Doom, Low detail for example.) - Jeff Lait (SOL) From charles Fri May 26 12:38:27 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sF5DE-000fJ5C; Fri, 26 May 95 12:38 PDT Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA04208; Fri, 26 May 1995 12:38:38 -0700 Message-Id: <9505261938.AA04208@rigel.krl.caltech.edu> Subject: Next step... To: ag-directors Date: Fri, 26 May 1995 12:38:38 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1076 Greetings, Now that we have at least one picture, and the archives are up, I think we are just about ready to start advertising. Could each of the directors make up a list of people who they need to fill in gaps. Also start preparing to take an influx of new people. With the web pages and us now showing that we're doing something real, we should get a *lot*. For each of the directors tell me: 1) When you will have the time to spend on the new members joining the project (we should wait until it will be convienient for people) 2) If you want to add anything to the web pages before we do (if you do, we can also wait for that before we make any announcements). 3) Any specific positions you will be looking for people to fill. 4) Any advertising places I might be missing. The places I've thought of to send out the web-page announcement are: our ag-announce mailing list comp.www.infosystems.announce comp.ai.alife comp.ai.games comp.ai rec.games.design rec.games.programmer rec.games.misc various artificial life web sites where else? --- Charles From undergrad.math.uwaterloo.ca!jmlait Fri May 26 19:41:34 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFBoQ-000fJ5C; Fri, 26 May 95 19:41 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56892-3>; Fri, 26 May 1995 22:41:01 -0400 Date: Fri, 26 May 1995 22:40:57 -0400 From: Jeff Lait To: Splinterwood cc: ag-directors@krl.caltech.edu Subject: Re: FE-PCX Recruitment. In-Reply-To: <9505261938.AA04208@rigel.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 26 May 1995, Splinterwood wrote: > 1) When you will have the time to spend on the new members joining the > project (we should wait until it will be convienient for people) I'd like to wait until we get the Universe/FE interface hammered out. When that is accomplished, we will be in a beter position to see what will needs to be done. > 2) If you want to add anything to the web pages before we do (if you do, > we can also wait for that before we make any announcements). Perhaps a cut down version of evilutio.doc for a sort of FE-PCX faq (Ie:, the tmapper/screen res/What are POC I-III sections. Ie: Sections 0, 3, 4) > 3) Any specific positions you will be looking for people to fill. I believe (??) we lack any sound board programmers - my experience is limitted & I don't recall any other members listing that as a talent. Beyond that, I believe we have plenty of talent already. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Fri May 26 19:49:09 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFBw2-000fJ5C; Fri, 26 May 95 19:49 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56884-2>; Fri, 26 May 1995 22:48:45 -0400 Date: Fri, 26 May 1995 22:48:42 -0400 From: Jeff Lait To: Splinterwood cc: ag-directors@krl.caltech.edu Subject: RE: Art-Sound Recruitment. In-Reply-To: <9505261938.AA04208@rigel.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 26 May 1995, Splinterwood wrote: > 1) When you will have the time to spend on the new members joining the > project (we should wait until it will be convienient for people) Currently we appear to not be getting anywhere in the evolving music/fx discussions, so new life should prove beneficial in providing different ideas. This whole area isn't getting much stuff right now as a lot of it depends on other areas... (Ie: universe, alife, and FE :>) > 2) If you want to add anything to the web pages before we do (if you do, > we can also wait for that before we make any announcements). Again, Art-Sound hasn't had too much to add. > 3) Any specific positions you will be looking for people to fill. Directorship for the Sound Component??? Artistic people for generating the movies...??? Though I currently have directorship of Art-Sound, I personally do not feel qualified for handling the artistic aspect of it, (I'm Pure Math, not an Arts student :>) and the only part which concerns me is the coding aspect, ie: movie format, tmapped creature evolution, etc. I really can't claim much talent in laying out a movie - sure, I can raytrace scenes once the POV files generated, and do simple Ball On Chessboard stuff, but I don't particularly relish running the creative aspects of both Sound & Art. - Jeff Lait (SOL) From mcl.ucsb.edu!uwingcat Sat May 27 12:23:42 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFRSQ-000fJ6C; Sat, 27 May 95 12:23 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id MAA12933; Sat, 27 May 1995 12:23:23 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id MAA00675; Sat, 27 May 1995 12:23:24 -0700 Message-Id: <199505271923.MAA00675@mcl.mcl.ucsb.edu> Subject: Re: Universe Status Report & FE-PCX (fwd) To: ag-directors@krl.caltech.edu Date: Sat, 27 May 1995 12:23:24 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6489 [x and y accuracy discussion snipped] > ?? The way I proposed was to store it as: > 33222222222211111111110000000000 > 10987654321098765432109876543210 > | || || | > | | +------------ Fractional subsector position. > | +----------------------- Integral subsector position. > +------------------------------- Subsector #. > Thus, we can have movement rates with 16 binary points in them. > How does this not solve the precision problem??? I didn't see that you were breaking the within-subsector position into fractional and integral parts. We'll need an extra two bits (maybe just one?) to handle position overflow (aka: torriodal wraparound space), so maybe we should start the within-subsector position at bit 23. This could be considered by the fron end as 8.24 fixed point, and would solve the accuracy problem. > > > If you think this is a problem (Which I don't) make a linked list > > > of object heaps & a linked list of disposed objects. New heap allocation > > > is a bit slower than equivalent malloc, but later so long as the disposed > > > heap is non empty one has little problems. Big problem with this is that > > > you can't free memory - as soon as a heap is allocated, it is pretty much > > > in memory until you quit, start a new game, or run a (slow!) compression > > > on it. > > > > Big problem is right: so what happens when we max out memory in > > mid-game? Slow compressions during the game would stop the action > > arbitrarily. > > On the other hand, compare this to suddenly being unable to fire > part way through the game Remember, the number of heaps allocated will > never be more than MAXOBJECT/HEAP_SIZE, where MAXOBJECT is the maximum > number of objects ever apearing in the game. Sure the user might get a > momentary glitch, but this would occur only if they are short on RAM in > the first place (I don't see a 16meg machine ever having to do this). > Presumably, you will still have MaxShips at which point you stop creating > ships, but we should never stop creating bullets/whatever. > Also, this allows us to run with less memory on machines with little > memory, as we can set MaxShips at runtime, possibly at the users request. Another possibility: play with UN_ReSeed() to keep the object number constant, leaving a large enough space between the number of currently present objects and the maximum possible number of objects to allow a sudden flurry of bullet creation, and only allow rapid creation of objects at a large cost in energy (so we don't see a lot of machine guns going at once, or if we do, the bullets die off fast enough that the rise in the number of objects eventually levels off). We might also remove asteroids (and maybe other inanimate objects) if there are no objects near them, if this is needed to get the object number down. > (Incidentally, didn't the original array have an array of > POINTERS to objects? Which means one would need to allocate them > anyways??? Probably a typo, no?, as it doesn't seem inline with what > you've been saying....) The objects are allocated before the game starts. The reason that we have object *objects[MAXOBJECTS], *sector[NUMSUBS][NUMSUBS]; is that this allows us to only move around the pointers to the objects when an object changes subsectors, or we move something around in the objects[] array (as we do when a new incarnation of the player appears). > > > Whoa... That assumes a constant frame rate, not only between > > > computers, but between frames! Each object must take into account the > > > time since the last frame, not the number of frames. > > > > We already have code that ensures a constant frame per CPU cycle ratio. > > It is FE's responsibility to ensure a constant frame per time ratio > > between computers, if desired. > > Hey... We aren't miracle workers here. The speed of frames WILL > change during game time if more objects are to be drawn and/or the user > changes detail levels. In any case, a constant "universe time" per update is assumed. > > Here's the relevant code, cut from a while(1) loop: > > > > /* set loop variables */ > > for (curobj=0;curobj > if (object[curobj].life>0) UN_UpdateObject(object[curobj]); > > if (objects[0]->curarm<=0) { AS_PlayFX(FX_DIE); > > if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } > > /* UN_NewLife() returns 1 if no lives left for the player */ > > while (ticksper>FE_GetTicks(lasticks)) AI_DoQueue(lasticks); > > lasticks=FE_Update(); > > /* check for syskeys and victory conditions */ > > > > FE_Update() and FE_GetTicks() are expected to adjust their returned > > values if the user presses the turbo button in mid-game, if we want to > > let the user do that. > > > What is ticksper? How is it determined? And most importantly, > what if FE takes longer than ticksper? And if it does, and ticksper is > then increased, what if FE takes less time than is expected? This > appears to assume that FE_Update() will always take constant time, > something we cannot guarantee. That is why I suggested time should be > included - it removes all these worries at a very small expense. ticksper is assigned by FE. Should ticksper be updated after each call to FE_Update()? The intention was to allow FE to tell UN and AI how many CPU cycles are left; UN and AI would then use the spare cycles for queued tasks. > > > Remember, when you're fighting in a swamr of aliens, firing > > > bullets wildly, the frame rate will likely drop from when you are > > > cruising interstellar space... > > > > Actually, no. Not the way that we're implementing it, anyway... > > > So what do we do, not draw half the bullets??? No, we just shelve the "background" AI tasks until less objects are being drawn. > Sheesh, either give the probes or the player the advantage I > say. Realism is all cool and all, but a lot of people would throw away > realism if that's the only way you can play full screen. > (Doom, Low detail for example.) Hmm...in that case, a 4:3 screen sounds best. Just as long as I know how many subsectors the player can see, so I can code the player's targetting algorithm correctly. BTW, universe.c 0.40 is done, shall I forward a copy to the director's list? It isn't a completed version, but it should clarify the UN <-> FE, UN <-> AS, and UN <-> AI interfaces. From post.demon.co.uk!darkin.demon.co.uk!Christian Sat May 27 13:24:44 1995 Return-Path: <@post.demon.co.uk:Christian@darkin.demon.co.uk> Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFSPV-000fJ5C; Sat, 27 May 95 13:24 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id aa09689; 27 May 95 12:39 +0100 Received: from darkin.demon.co.uk by post.demon.co.uk id aa03563; 27 May 95 12:39 +0100 Date: Sat, 27 May 1995 09:33:22 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <203@darkin.demon.co.uk> To: ag-directors@alnilam.krl.caltech.edu Subject: Re: Next step... X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 57 In your message dated Friday 26, May 1995 you wrote : > Greetings, > > Now that we have at least one picture, and the archives are up, I > think we are just about ready to start advertising. Could each of the > directors make up a list of people who they need to fill in gaps. Also > start preparing to take an influx of new people. With the web pages and > us now showing that we're doing something real, we should get a *lot*. > > For each of the directors tell me: > > 1) When you will have the time to spend on the new members joining the > project (we should wait until it will be convienient for people) > 2) If you want to add anything to the web pages before we do (if you do, > we can also wait for that before we make any announcements). > 3) Any specific positions you will be looking for people to fill. > 4) Any advertising places I might be missing. > > The places I've thought of to send out the web-page announcement are: > > our ag-announce mailing list > comp.www.infosystems.announce > comp.ai.alife > comp.ai.games > comp.ai > rec.games.design > rec.games.programmer > rec.games.misc > various artificial life web sites > > where else? Just going through my usenet list: Ah, how about: comp.graphics.animation comp.graphics.raytracing comp.graphics.algorithms alt.music.makers.electronic alt.music.video.games comp.music and alt.wanted.people.to.write.wierd.games.full.of.evolving.aliens > > --- Charles > > -- Christian Darkin From charles Sun May 28 13:36:36 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFp4Z-000fJ5C; Sun, 28 May 95 13:36 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA28269; Sun, 28 May 1995 13:37:04 -0700 Message-Id: <9505282037.AA28269@altair.krl.caltech.edu> Subject: Re: Next step... To: ag-directors Date: Sun, 28 May 1995 13:37:04 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 460 > Ah, how about: > > comp.graphics.animation > comp.graphics.raytracing > comp.graphics.algorithms > > alt.music.makers.electronic > alt.music.video.games > comp.music All of these sound good, but I think we should send a specialized message to them which is more fitting with what the newsgroup is (ie specifically looking for art or sound people). > alt.wanted.people.to.write.wierd.games.full.of.evolving.aliens ummm... go for it... --- Charles From charles Sun May 28 13:45:29 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFpDD-000fJ5C; Sun, 28 May 95 13:45 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA29418; Sun, 28 May 1995 13:45:59 -0700 Message-Id: <9505282045.AA29418@altair.krl.caltech.edu> Subject: RE: Art-Sound Recruitment. To: ag-directors Date: Sun, 28 May 1995 13:45:59 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1050 > > 3) Any specific positions you will be looking for people to fill. > > Directorship for the Sound Component??? Hmmm... I think we should wait on this until we get to know some of the new people coming onto the project. > Artistic people for generating the movies...??? Though I > currently have directorship of Art-Sound, I personally do not feel > qualified for handling the artistic aspect of it, (I'm Pure Math, not an > Arts student :>) and the only part which concerns me is the coding > aspect, ie: movie format, tmapped creature evolution, etc. I really > can't claim much talent in laying out a movie - sure, I can raytrace > scenes once the POV files generated, and do simple Ball On Chessboard > stuff, but I don't particularly relish running the creative aspects of > both Sound & Art. As a director, you certainly don't need to do all of the work. Graphics and sound people will be key things we're targeting. Christian had a good idea of specifically selecting those newsgroups to get them from. --- Charles From charles Sun May 28 13:48:20 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFpFy-000fJ5C; Sun, 28 May 95 13:48 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA29409; Sun, 28 May 1995 13:48:50 -0700 Message-Id: <9505282048.AA29409@altair.krl.caltech.edu> Subject: Re: FE-PCX Recruitment. To: ag-directors Date: Sun, 28 May 1995 13:48:50 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1134 > > 1) When you will have the time to spend on the new members joining the > > project (we should wait until it will be convienient for people) > > I'd like to wait until we get the Universe/FE interface hammered > out. When that is accomplished, we will be in a beter position to see > what will needs to be done. Sounds like a good idea. We're well on our way in that direction. > > 2) If you want to add anything to the web pages before we do (if you do, > > we can also wait for that before we make any announcements). > > Perhaps a cut down version of evilutio.doc for a sort of FE-PCX > faq (Ie:, the tmapper/screen res/What are POC I-III sections. Ie: > Sections 0, 3, 4) Ummm.. I think I might have missed/mis-placed this document; could you send me another copy please? Thanx... > > 3) Any specific positions you will be looking for people to fill. > > I believe (??) we lack any sound board programmers - my > experience is limitted & I don't recall any other members listing that as > a talent. Beyond that, I believe we have plenty of talent already. Will add that to the list. --- Charles From undergrad.math.uwaterloo.ca!jmlait Sun May 28 19:00:15 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFu7l-000fJ5C; Sun, 28 May 95 19:00 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56892-3>; Sun, 28 May 1995 21:59:59 -0400 Date: Sun, 28 May 1995 21:59:47 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Debate continues... In-Reply-To: <199505271923.MAA00675@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 27 May 1995, Adrian Tymes wrote: > I didn't see that you were breaking the within-subsector position into > fractional and integral parts. We'll need an extra two bits (maybe just > one?) to handle position overflow (aka: torriodal wraparound space), so > maybe we should start the within-subsector position at bit 23. This > could be considered by the fron end as 8.24 fixed point, and would solve the > accuracy problem. > ?? Again why? In case of position over flow, isn't the correct response to increment/decrement the subsect # based upon the carry, which is what this will do automagically in a 6:10:16 scheme? > > On the other hand, compare this to suddenly being unable to fire > > part way through the game Remember, the number of heaps allocated will > > never be more than MAXOBJECT/HEAP_SIZE, where MAXOBJECT is the maximum > > number of objects ever apearing in the game. Sure the user might get a > > momentary glitch, but this would occur only if they are short on RAM in > > the first place (I don't see a 16meg machine ever having to do this). > > Presumably, you will still have MaxShips at which point you stop creating > > ships, but we should never stop creating bullets/whatever. > > Also, this allows us to run with less memory on machines with little > > memory, as we can set MaxShips at runtime, possibly at the users request. > > Another possibility: play with UN_ReSeed() to keep the object number > constant, leaving a large enough space between the number of currently > present objects and the maximum possible number of objects to allow a > sudden flurry of bullet creation, and only allow rapid creation of > objects at a large cost in energy (so we don't see a lot of machine guns > going at once, or if we do, the bullets die off fast enough that the rise > in the number of objects eventually levels off). We might also remove > asteroids (and maybe other inanimate objects) if there are no objects > near them, if this is needed to get the object number down. > Again, what is a good safety margin? As for this alternative, it sounds like a complicated work around where just throwing it to a heaped base method would be just as effective. > > (Incidentally, didn't the original array have an array of > > POINTERS to objects? Which means one would need to allocate them > > anyways??? Probably a typo, no?, as it doesn't seem inline with what > > you've been saying....) > > The objects are allocated before the game starts. The reason that we have > object *objects[MAXOBJECTS], *sector[NUMSUBS][NUMSUBS]; > is that this allows us to only move around the pointers to the objects > when an object changes subsectors, or we move something around in the > objects[] array (as we do when a new incarnation of the player appears). > In this case, definitely don't have a object *objects[] structure! The new player problem is easy to do just having the player as the root of the object list. There are no allocs associated with creating a new object cause we just pull it off the deleted objects list (probably using the same pointers as the other way) and through it behind the player's object. If the list is double linked, deletions are simple. I don't see where random access to the object list is req'd, or where it is required, the pointer to the object is not already known, and hence an access irrelevant. Using a fixed array for sectors OTOH makes sense, after all, each sector is just the head of a chain of objects. > > > Here's the relevant code, cut from a while(1) loop: > > > > > > /* set loop variables */ > > > for (curobj=0;curobj > > if (object[curobj].life>0) UN_UpdateObject(object[curobj]); > > > if (objects[0]->curarm<=0) { AS_PlayFX(FX_DIE); > > > if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } > > > /* UN_NewLife() returns 1 if no lives left for the player */ > > > while (ticksper>FE_GetTicks(lasticks)) AI_DoQueue(lasticks); > > > lasticks=FE_Update(); > > > /* check for syskeys and victory conditions */ > > > > > > FE_Update() and FE_GetTicks() are expected to adjust their returned > > > values if the user presses the turbo button in mid-game, if we want to > > > let the user do that. > > > > > What is ticksper? How is it determined? And most importantly, > > what if FE takes longer than ticksper? And if it does, and ticksper is > > then increased, what if FE takes less time than is expected? This > > appears to assume that FE_Update() will always take constant time, > > something we cannot guarantee. That is why I suggested time should be > > included - it removes all these worries at a very small expense. > > ticksper is assigned by FE. Should ticksper be updated after each call > to FE_Update()? The intention was to allow FE to tell UN and AI how many > CPU cycles are left; UN and AI would then use the spare cycles for queued > tasks. > The trouble with this that I see is: 1) ticksper too low, queued over fills, more tasks craeted than time given. 2) ticksper too high, queue is quickly emptied, processor sits there idling, when it could be starting the next frame. Now, why can't FE update the ticksper dynamically? Well, if it did, everything would behave odd - ie: one frame ticksper is at 1 second, next at .5 seconds (Exagerated here:>) but in both time periods all the objects move the same distance! In other words, for it to update ticks per dynamically, the universe would have to use it in it's displacement calculation, and it would be in all effects the equivalent to the `time' I mentioned before. I presume the goal is to allow you to displace the queued actions over time, so why not assign some percentage of time to emptying the queue, varying on the size of the queue and time taking in the last frame, ie: prevtime = time; start = FE_GetTicks(); // Displace all objects with previous frames time. // Redraw screen. end = FE_GetTicks(); time = start - end; // Now, if Queues are supposed to take at most 25%, we could: endingtime = time + (time + 3)/4; while (FE_GetTicks < endingtime && Queue not empty) { // Do queues... } time = FE_GetTicks() - start; // Get total time for frame. well, you could use the previous frames time to get an idea of how long you should spend on queues... > > So what do we do, not draw half the bullets??? > > No, we just shelve the "background" AI tasks until less objects are > being drawn. Ah.. But I'm talking about FE redrawing these bullets on screen. FE's frame rate will change, possible exceeding ticksper. > Hmm...in that case, a 4:3 screen sounds best. Just as long as I know how > many subsectors the player can see, so I can code the player's targetting > algorithm correctly. Sure, we'll work out details later, so long as full screen is possible I'm happy :> > BTW, universe.c 0.40 is done, shall I forward a copy to the director's > list? It isn't a completed version, but it should clarify the UN <-> FE, > UN <-> AS, and UN <-> AI interfaces. > Please do... I'd like to fix up a POC IV which is based off the universe code... I don't feel like rewriting it all in order to get some more functionality out of POC III :> - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Sun May 28 19:09:10 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFuGR-000fJ5C; Sun, 28 May 95 19:09 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56892-3>; Sun, 28 May 1995 22:08:55 -0400 Date: Sun, 28 May 1995 22:08:43 -0400 From: Jeff Lait To: Splinterwood cc: ag-directors@krl.caltech.edu Subject: Re: FE-PCX Recruitment. In-Reply-To: <9505282048.AA29409@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 28 May 1995, Splinterwood wrote: > > > 2) If you want to add anything to the web pages before we do (if you do, > > > we can also wait for that before we make any announcements). > > > > Perhaps a cut down version of evilutio.doc for a sort of FE-PCX > > faq (Ie:, the tmapper/screen res/What are POC I-III sections. Ie: > > Sections 0, 3, 4) > > Ummm.. I think I might have missed/mis-placed this document; could you > send me another copy please? Thanx... > It was in POC III, which was sent to the info FTP site. If you still can't get it, p-mail me and I'll send it to you. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Sun May 28 19:25:42 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sFuWR-000fJ5C; Sun, 28 May 95 19:25 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56951-1>; Sun, 28 May 1995 22:25:26 -0400 Date: Sun, 28 May 1995 22:25:24 -0400 From: Jeff Lait To: Splinterwood cc: ag-directors@krl.caltech.edu Subject: RE: Art-Sound Recruitment. In-Reply-To: <9505282045.AA29418@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 28 May 1995, Splinterwood wrote: > As a director, you certainly don't need to do all of the work. Graphics > and sound people will be key things we're targeting. Christian had a > good idea of specifically selecting those newsgroups to get them from. True.. However, my point was that I'm probably not qualified to lead in a field where i have little talent. Same with the music/fx department. I have nothing agains leading the coding, just I'd think it would work better if someone with greater talents/interests took up the torch on handling hte creative directing. - Jeff Lait (SOL) From phil.ruu.nl!faassen Mon May 29 12:31:22 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGAWs-000fJ6C; Mon, 29 May 95 12:31 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id VAA13261; Mon, 29 May 1995 21:31:01 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id VAA04773; Mon, 29 May 1995 21:30:56 +0200 From: Martijn Faassen Message-Id: <199505291930.VAA04773@laurel.stud.phil.ruu.nl> Subject: AI view size. To: ag-directors@alnilam.krl.caltech.edu (AG Directors), ag-fe@krl.caltech.edu (fe) Date: Mon, 29 May 1995 21:30:56 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1299 > > Which is all fine. So why not either: > > A) Give the probes a 4:3 viewing area (or 12:9) > > AI had objections to this, I forget what they were... We may have had objections..I'm not sure what they were either, however. The only objections I can come up with are: - processing time But it is probably not true that it costs more CPU time with nonsquare. - confusion of probes because of nonsquare view area. Possible, but probably not something we should overly worry about. (they'll probably be confused anyway, let's just hope not terminally confused :) So, if the rest of the alife group can't come up with more objections, I don't see any trouble with nonsquare viewing areas. It's up to Universe and FE. (alife may play around with viewing areas for probes anyway, I imagine? what if we increase, decrease, stretch, etc, them?) (is the aspect ratio of a Mac similar to that of PC, though? is this relevant?) > > B) Give the human the minor advantage of a slightly larger > > viewing area. > > I don't think many avid game players would welcome the idea of a > > reduced viewscreen. 'Specially considerign the fact we hardly need to > > reduce it for speed reasons: Alife would run just as fast and FE-PCX at > > least would hardly feel the change. Martijn From phil.ruu.nl!faassen Mon May 29 12:37:57 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGAdO-000fJ5C; Mon, 29 May 95 12:37 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id VAA13405 for ; Mon, 29 May 1995 21:37:48 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id VAA04787 for ag-directors@alnilam.krl.caltech.edu; Mon, 29 May 1995 21:37:45 +0200 From: Martijn Faassen Message-Id: <199505291937.VAA04787@laurel.stud.phil.ruu.nl> Subject: Re: bounding box size To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 29 May 1995 21:37:44 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1222 > > Bbox size is evolved, as is the probe's bitmap. Starting positions are > > specified relative to creators' positions, if applicable. What other > > universe/front end info is there? > > > Une question, SVP! How variable is the bounding box? Is the > FE-PCX's request of only having a limited number of different sized > objects, and having all bullets symmetrical, accepted? It would be a > performance hit if it is not - we're all ready running at 10-13 cycles/pixel > (depending upon whether pixel is clear). The inner loop would stay the > same, but the outer loop would have a LOT more overhead. > - Jeff Lait (SOL) I *thought* bbox sizes were not smoothly variable, there was a discussion on this before? Anyway, I sent off a mail to somewhere (look in the archives? :) discussing how to use sizes. Something like this: Large: big asteroid, boss probe, supply ship Medium: asteroid, probe Small: small asteroid, (maybe) small probe, missile (?), egg Tiny: bullet (?) (a player ship is a probe, add various instances of dead probes, eggs, etc) Anyway, maybe there are more size classes, maybe less. We should determine this depending on how it looks on the screen/affects gameplay. Martijn From phil.ruu.nl!faassen Mon May 29 14:02:04 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGBwn-000fJ5C; Mon, 29 May 95 14:02 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id XAA14899 for ; Mon, 29 May 1995 23:01:55 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id XAA04891 for ag-directors@alnilam.krl.caltech.edu; Mon, 29 May 1995 23:01:51 +0200 From: Martijn Faassen Message-Id: <199505292101.XAA04891@laurel.stud.phil.ruu.nl> Subject: Script of Intro Movie To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 29 May 1995 23:01:50 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 601 Hello, As I recall there was a question on the script/plot of the game coming from Art/Sound, the intro movie script I wrote is on our web page (both a summary and a full version). I think, it being on the web page, it has been approved as 'the official script', so Art/Sound could start creating the intro movie. If clarifications are needed, please contact me. When Art/Sound has done that, we'll probably be ready to supply them with more plot! Can anyone forward this information to the art/sound group? Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From undergrad.math.uwaterloo.ca!jmlait Mon May 29 14:57:12 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGCo7-000fJ5C; Mon, 29 May 95 14:57 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56994-1>; Mon, 29 May 1995 17:56:58 -0400 Date: Mon, 29 May 1995 17:56:45 -0400 From: Jeff Lait To: Martijn Faassen cc: AG Directors Subject: Re: bounding box size In-Reply-To: <199505291937.VAA04787@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 29 May 1995, Martijn Faassen wrote: > Large: big asteroid, boss probe, supply ship > Medium: asteroid, probe > Small: small asteroid, (maybe) small probe, missile (?), egg > Tiny: bullet (?) > (a player ship is a probe, add various instances of dead probes, eggs, etc) > > Anyway, maybe there are more size classes, maybe less. We should determine > this depending on how it looks on the screen/affects gameplay. > On a slightly related note,it would be a good idea to classify certain things (Such as bullets, eggs?) as symmetrical: ie: they do not need to be rotated and the rotate angle can be ignored. This would allow the FEs to appropriately optimize these objects. This would also apply to static background objects. - Jeff Lait (SOL) From mcl.ucsb.edu!uwingcat Mon May 29 20:22:23 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGHsp-000fJ6C; Mon, 29 May 95 20:22 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id UAA08581; Mon, 29 May 1995 20:22:13 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id UAA13741; Mon, 29 May 1995 20:22:12 -0700 Message-Id: <199505300322.UAA13741@mcl.mcl.ucsb.edu> Subject: Debate continues... (fwd) To: ag-directors@krl.caltech.edu Date: Mon, 29 May 1995 20:22:12 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6583 > > I didn't see that you were breaking the within-subsector position into > > fractional and integral parts. We'll need an extra two bits (maybe just > > one?) to handle position overflow (aka: torriodal wraparound space), so > > maybe we should start the within-subsector position at bit 23. This > > could be considered by the fron end as 8.24 fixed point, and would solve the > > accuracy problem. > > > ?? Again why? In case of position over flow, isn't the correct > response to increment/decrement the subsect # based upon the carry, which > is what this will do automagically in a 6:10:16 scheme? Remember: the universe.c part is in ANSI C, which can't read the carry/ overflow bits, TMK. So we have to determine whether we increment/decrement based on if x<0 or x>MAX_X, and similarly for y. This requires the extra bit(s). > > > On the other hand, compare this to suddenly being unable to fire > > > part way through the game Remember, the number of heaps allocated will > > > never be more than MAXOBJECT/HEAP_SIZE, where MAXOBJECT is the maximum > > > number of objects ever apearing in the game. Sure the user might get a > > > momentary glitch, but this would occur only if they are short on RAM in > > > the first place (I don't see a 16meg machine ever having to do this). > > > Presumably, you will still have MaxShips at which point you stop creating > > > ships, but we should never stop creating bullets/whatever. > > > Also, this allows us to run with less memory on machines with little > > > memory, as we can set MaxShips at runtime, possibly at the users request. > > > > Another possibility: play with UN_ReSeed() to keep the object number > > constant, leaving a large enough space between the number of currently > > present objects and the maximum possible number of objects to allow a > > sudden flurry of bullet creation, and only allow rapid creation of > > objects at a large cost in energy (so we don't see a lot of machine guns > > going at once, or if we do, the bullets die off fast enough that the rise > > in the number of objects eventually levels off). We might also remove > > asteroids (and maybe other inanimate objects) if there are no objects > > near them, if this is needed to get the object number down. > > > Again, what is a good safety margin? As for this alternative, it > sounds like a complicated work around where just throwing it to a heaped > base method would be just as effective. UN_ReSeed() can probably do it faster, since it's going to be called anyway, and this would be an ideal control parameter for it. We'll have to experiment with good safety margins based on average and peak rates of fire, usual number of probes shooting at each other, and other things that won't be known until after we get this program running, regardless of how we handle objects[]. > > > (Incidentally, didn't the original array have an array of > > > POINTERS to objects? Which means one would need to allocate them > > > anyways??? Probably a typo, no?, as it doesn't seem inline with what > > > you've been saying....) > > > > The objects are allocated before the game starts. The reason that we have > > object *objects[MAXOBJECTS], *sector[NUMSUBS][NUMSUBS]; > > is that this allows us to only move around the pointers to the objects > > when an object changes subsectors, or we move something around in the > > objects[] array (as we do when a new incarnation of the player appears). > > > In this case, definitely don't have a object *objects[] > structure! The new player problem is easy to do just having the player > as the root of the object list. There are no allocs associated with > creating a new object cause we just pull it off the deleted objects list > (probably using the same pointers as the other way) and through it behind > the player's object. If the list is double linked, deletions are > simple. I don't see where random access to the object list is req'd, or > where it is required, the pointer to the object is not already known, and > hence an access irrelevant. Using a fixed array for sectors OTOH makes > sense, after all, each sector is just the head of a chain of objects. Hmm...actually, we may already be doing this approach. objects[] points to all of the objects in existence, and they are only drawn if objects[n].shield > 0 . > > > > Here's the relevant code, cut from a while(1) loop: > > > > > > > > /* set loop variables */ > > > > for (curobj=0;curobj > > > if (object[curobj].life>0) UN_UpdateObject(object[curobj]); > > > > if (objects[0]->curarm<=0) { AS_PlayFX(FX_DIE); > > > > if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } > > > > /* UN_NewLife() returns 1 if no lives left for the player */ > > > > while (ticksper>FE_GetTicks(lasticks)) AI_DoQueue(lasticks); > > > > lasticks=FE_Update(); > > > > /* check for syskeys and victory conditions */ > > > > > > > > FE_Update() and FE_GetTicks() are expected to adjust their returned > > > > values if the user presses the turbo button in mid-game, if we want to > > > > let the user do that. > > FE's frame rate will change, possible exceeding ticksper. It is FE's responsibility to assign ticksper so that this never happens. Different times between frames are a bad idea: the disruption between frames will probably be perceived. If they are, then making universe time based off of real time will be even worse: in the middle of a burst of action, sudden 1-second (or even half-second) unexpected delays in the animation can severely mess up the player's situation (I speak from experience with programs that have done both of these, for instance Descent on a low-memory 486/50 and Paradise Netrek over a lagged connection, if you want to verify this). Trust me, if ticksper is high, the AI routines will probably evolve deep-thinking probes on that machine. Processing that thought will quickly use up the "leftover" cycles. So FE does not have to worry about idle CPUs, but it does have to worry about keeping the frame rate constant. > > Hmm...in that case, a 4:3 screen sounds best. Just as long as I know how > > many subsectors the player can see, so I can code the player's targetting > > algorithm correctly. > > Sure, we'll work out details later, so long as full screen is > possible I'm happy :> In that case, ignore the targetting code in universe.c 0.41, since it will need to be fixed *after* we know what the player can see...we want to make this the same as what the player can target. From mcl.ucsb.edu!uwingcat Mon May 29 20:36:58 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGI6w-000fJ5C; Mon, 29 May 95 20:36 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id UAA10581 for ; Mon, 29 May 1995 20:36:49 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id UAA16418; Mon, 29 May 1995 20:36:48 -0700 Message-Id: <199505300336.UAA16418@mcl.mcl.ucsb.edu> Subject: universe.c 0.41 To: ag-directors@krl.caltech.edu Date: Mon, 29 May 1995 20:36:48 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 24228 /* Universe code version 0.41, copyright us 5/29/1995 */ /* defines for object->what note that all animate objects are <= MISSILE (assuming BULLET exhibits no behaviour, just goes on momentum) */ #define PLAYER 0 #define PROBE 1 #define SUPPLY 2 #define MISSILE 3 #define BULLET 4 #define ASTEROID 5 #define UF_EGG 6 #define F_EGG 7 #define D_EGG 8 #define D_PLAYER 9 #define D_PROBE 10 #define D_SUPPLY 11 #define UNMOVABLE 12 #define SPECIAL 13 /* more #defines */ #define SUBSIZE 16777216 #define SUBPOWER 24 /* SUBPOWER = log(base2) (SUBSIZE) */ /* intended use: floor(z / SUBSIZE) == z >> SUBPOWER; the second is faster */ #define NUMSUBS 64 #define MAXOBJECTS 100 /* ONLY FOR NOW!!! When we get the program operational, MAXOBJECTS will probably be greatly increased */ #define MAX_X SUBSIZE*NUMSUBS #define MAX_Y SUBSIZE*NUMSUBS #define MAX_BBSIDE SUBSIZE /* standard object definition */ /* Explanation of structure: typedef struct ob { long x, y: location of object (needs to be signed: the code assumes that the values can be < 0, and the code won't work otherwise...in this case because of the torrodial space implementation) long velx, vely: movement vector (needs to be signed) picture *pic: picture for FE and AS unsigned long what: what the object is: PLAYER - player PROBE - probe ASTEROID - asteroid BULLET - bullet (aka: brain-dead missile) MISSILE - missile (aka: homing bullet) UF_EGG - unfertilized egg F_EGG - fertilized egg D_EGG - dead egg D_PLAYER - dead player D_PROBE - dead probe SUPPLY - supply ship D_SUPPLY - dead supply ship UNMOVABLE - unmovable object SPECIAL - special object long facdir: facing direction 0...255 (needs to be signed) PLAYER PROBE SUPPLY BULLET MISSILE: for navigation PLAYER PROBE SUPPLY?: for firing every object: for animations, for example a collision objects may perhaps turn - or perhaps not unsigned long mass: mass of object NOTE: mass should *never* be zero!! (and mass shouldn't be too low either) PLAYER PROBE SUPPLY BULLET MISSILE: thrust needs this every object: collision needs this unsigned long bboxside: length of side of bounding box every object: collision needs this */ long shield: currently remaining shield of object (needs to be signed) every object: if shield <= zero then the object dies What happens upon death: PLAYER -> D_PLAYER PROBE -> D_PROBE ASTEROID -> breaks into smaller asteroids or vanishes BULLET -> explodes, then vanishes MISSILE -> explodes, then vanishes UF_EGG -> D_EGG F_EGG -> D_EGG D_EGG -> vanishes D_PLAYER -> vanishes D_PROBE -> vanishes SUPPLY -> D_SUPPLY D_SUPPLY -> vanishes UNMOVABLE -> vanishes (or may be indestructable?) SPECIAL -> depends on what we do with this long energy: currently remaining energy of object (needs to be signed) can be used for navigation/firing by animate objects, and is used to denote nutricious value for inanimate objects PLAYER PROBE MISSILE SUPPLY: used for thrust PLAYER PROBE SUPPLY(?): for firing weapons PLAYER PROBE: to lay an egg, and to fertilize an egg UF_EGG: energy may decay slowly; also nutricious value F_EGG: energy is invested in properties; also nutricious value D_PLAYER D_PROBE D_SUPPLY D_EGG ASTEROID UNMOVABLE: nutricious value unsigned long age: Frames since creation or last "what" change - probes may use age to base actions on - eggs can hatch at a certain time after fertilisation - certain weapons may explode after a certain time - nutricious value (energy) of dead objects may degenerate with age - statistical purposes Now for the shared memory with extra non generic object information: union { struct { ob *target: current target of object long thrust: thrust power of object long turn: turn speed of object genotype *gtype: pointer to genotype of object - alife stuff weapon *wlist: pointer to the current weapon in the weapon list of this object - system needs to be refined later, but whatever this points to will be fired if the object fires action actions: virtual keypresses done by this probe } animate; (used by PLAYER, PROBE, and SUPPLY) struct { long damage: explosive force of BULLET long type: type of explosion (only contact-damage is supported right now) } bullet; (used by BULLET) (perhaps another struct for 'special' stuff, like food and eggs) } extra; ob *next_hash: pointer to next object in list ob **prev_hash: pointer to pointer at this object, **(ob->prev_hash)=ob if (ob!=first object on its sector list) *(ob->prev_hash)= previous_ob->next_hash else *(ob->prev_hash)= sector[ob->x >> SUBSIZE][ob->y >> SUBSIZE] If you're confused by this, UN_Shift() should clear up the way object->prev_hash, object->next_hash, and sector[][] are used. Note that this is only for objects in the objects[] array. There may be other objects that are on completely seperate lists (weapon lists, for instance?) } object; */ /* Condensed: */ typedef struct ob { long x, y; long velx, vely; picture *pic; long facdir, shield, energy; unsigned long what, mass, bboxside, age; union { struct { ob *target; long thrust,turn; genotype *gtype; weapon *wlist; action actions; } animate; struct { long damage, type; } bullet; } extra; ob *next_hash, **prev_hash; } object; object *objects[MAXOBJECTS]; object *sector[NUMSUB][NUMSUB]; /* objects contains pointers to all objects in play (and possibly more: if ** objects[n]->shield<=0, the object won't be considered), sector contains ** the subsector lists */ char curwhat; /* current what the object is */ long probes_exist; /* probes still exist */ long curthrust; /* current thrust */ long tempx, tempy; /* temporary subsector holders */ long subx, suby; /* more temporary subsector holders */ float sin[256],cos[256]; /* precomputed sin and cos lookup tables */ long curobj; /* current object number */ long curpic; /* current picture number for object */ long xh,txh,ttxh,dx,yh,tyh,ttyh,dy; /* variables for collision detection */ /* current picture number = ** facing (0-255) + THRUSTPIC + BRAKEPIC + TARGETPIC */ #define THRUSTPIC 256 #define BRAKEPIC 512 #define TARGETPIC 1024 #define SYSKEYS objects[0]->extra.animate.actions /* objects[0] is always the current incarnation of the player, and system keys will always be passed to the universe (as opposed to main/menu) part of the game by the player's actions */ /* UN_CheckObject is called for each object each 'tick' */ UN_CheckObject (object *obj) { curwhat = obj->what; /* what the object is stored in curwhat */ tempx = obj->x/SUBSIZE; /* store subsector temporarily */ tempy = obj->y/SUBSIZE; curpic = 0; switch (curwhat) /* get keys & virtual keys */ { case PLAYER: /* this is the player */ obj->extra.animate.actions = FE_GetKeys(); /* get the real keypresses */ break; case PROBE: /* this is a probe */ probes_exist = 1; /* there's still probes in the battlefield */ /* get the virtual keypresses from a short AI routine - real alife work is done elsewhere */ obj->extra.animate.actions = AI_GetKeys(obj); break; /* case missile (probe remote control, and standard control routines) */ /* case SUPPLY */ } /* end of switch(curwhat) */ if (curwhat <= MISSILE) /* this is an animate object */ { if (obj->extra.animate.actions & THRUST) /* forward thrust */ { curthrust = obj->extra.animate.thrust; if (obj->energy - thrustcost[curthrust] >= 0) /* if enough energy */ { /* assuming navigation system with north = 0, clockwise increase calculate vector changes */ obj->velx += (curthrust/obj->mass) * sin[obj->facdir]; obj->vely += (curthrust/obj->mass) * cos[obj->facdir]; /* energy cost of this thrust */ obj->energy -= thrustcost[curthrust]; /* lookup for thrustcost */ curpic=THRUSTPIC; } else /* not enough energy for thrust */ { /* FE call here for thrust fail art/sound, currently none */ if (curwhat == PROBE) { /* hardware interrupt for AI note that hardware interrupts calls don't do anything directly; the interrupt is just registered, later the interrupt handler will handle it */ AI_interrupt(obj, THRUST_FAIL); } } /* end of not enough energy code */ } /* end of THRUST code */ else if (obj->extra.animate.actions & BRAKE) /* backward thrust */ { curthrust = obj->extra.animate.thrust; if (obj->energy - thrustcost[curthrust] >= 0) /* if enough energy */ { /* assuming navigation system with north = 0, clockwise increase calculate vector changes */ obj->velx -= (curthrust/obj->mass) * sin[obj->facdir]; obj->vely -= (curthrust/obj->mass) * cos[obj->facdir]; /* energy cost of this brake thrust */ obj->energy -= thrustcost[curthrust]; /* lookup for thrustcost */ curpic=BRAKEPIC; } else /* not enough energy for brake thrust */ { /* FE call here for brake thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, BRAKE_FAIL); /* hardware interrupt */ } } /* end of not enough energy code */ } /* end of BRAKE code - end of THRUST/BRAKE code */ /* NOTE: we might want to kick out different turn speeds, and use a standard turnspeed instead for each object */ if (obj->extra.animate.actions & LEFT) /* turn to the left */ { /* turning to left, so counterclockwise, means decreasing angle */ /* % operator doesn't work here, because when turning left the facdir will never rise above 255. Instead code is needed to handle facdir < 0. This code will break with turnspeed > 256 :) */ obj->facdir = (obj->facdir - obj->extra.animate.turn); if (obj->facdir < 0) { obj->facdir += 256; } /* alternatively (if faster?) use: obj->facdir = (256 + (obj->facdir - obj->extra.animate.turn)) % 256 */ } /* end of LEFT code */ else if (obj->extra.animate.actions & RIGHT) /* turn to the right */ { /* turning to the right, so clockwise, means increasing angle */ /* % operator is used */ obj->facdir = (obj->facdir + obj->extra.animate.turn) % 256; } /* end of RIGHT code */ /* target code for player only...probes handle this differently, and this ** only allows the player to target things in the 11*11 subsectors nearest to ** the subsector that the player is in, since this is what will be on the ** player's screen...and while we could allow the player to target anything, ** the player will probably not want to spend the time to cycle through ** everything that's out of sight to target an incoming food source */ /* note: this has bugs in it (especially the "last target" part), ** so IGNORE the target code for now. */ if (obj->actions & NEXTTARGET) { /* cycle to next target */ if ((obj->extra.animate.target)->next_hash!=NULL) obj->extra.animate.target= (obj->extra.animate.target)->next_hash; else { /* search through sectors to find a target */ long x=((obj->extra.animate.target)->x/SUBSIZE), y=((obj->extra.animate.target)->y/SUBSIZE); x++; if (x>tempx+5) {x=tempx-5; y++;} if (y>tempy+5) y=tempy-5; while (sector[(x+NUMSUBS)%NUMSUBS][(y+NUMSUBS)%NUMSUBS]==NULL) { x++; if (x>tempx+5) { x=x-11; y++; if (y>tempy+5) y=y-11;} } obj->extra.animate.target= sector[(x+NUMSUBS)%NUMSUBS][(y+NUMSUBS)%NUMSUBS]; } } /* sorry for the tab shifts above, but I don't know if I can break up the ** sector[formula][formula] without inducing a parsing error */ /* end of "next target" code */ else if (obj->actions & LASTTARGET) { /* find previous target */ object *tar=obj->extra.animate.target; if (tar->prev_hash!= &(sector[tar->x >> SUBPOWER][tar->y >> SUBPOWER])) obj->extra.animate.target= *(tar->prev_hash); else { /* cycle through sectors to find previous target */ long x=(tar->x >> SUBPOWER), y=(tar->y >> SUBPOWER); x--; if (xextra.animate.target= sector[(x+NUMSUBS)%NUMSUBS][(y+NUMSUBS)%NUMSUBS]; } } /* end of "last target" code; also end of player's "change target" code */ /* need to add in FIRE for PLAYER/PROBE */ /* need to add in cycle weapon code for PLAYER/PROBE */ /* one possibility: have objects outside of the objects[] array be the prototypes for each weapon, with next_hash/prev_hash forming a circular double-linked list for each object; cycle weapon would then get the next (or previous) object on that list, while fire would merely make a duplicate of that weapon into objects[], editing velocity, position, and (if needed) target as needed */ /* need to add in energy to shield code for PLAYER/PROBE/SUPPLY */ /* need to add in breed stuff */ /* need to add in pick up/drop */ /* these last two could merely set flags (for instance, object->extra.animate.actions & BREED) that could be checked if the object bumps into another object, since fertilization and grabbing will only be processed when an object that is trying to do that comes into contact with another one */ } /* end if animate */ if (objects[0]->extra.animate.target == obj) curpic += TARGETPIC; AS_SetPic(obj->pic,(curpic)&((obj->facdir + 256)%256)); /* Sets the current picture so FE can just display it if it is visible, also allows cycling of colors. We may want to move this to after the collision detection. */ /* Movement update */ obj->x += obj->velx; obj->y += obj->vely; /* torrodial space implementation */ if (obj->x < 0) { obj->x += MAX_X; /* note that MAX_X should be total amount of horizontal universe points, not the maximum value x can take (which is one less) */ } else if (obj->x >= MAX_X) { obj->x -= MAX_X; } if (obj->y < 0) { obj->y += MAX_Y; /* same note as for MAX_X */ } else if (obj->y >= MAX_Y) { obj->y -= MAX_Y; } /* alternative torrodial space implementation - which is faster? */ /* start commented code obj->x = (MAX_X + obj->x) % MAX_X; obj->y = (MAX_Y + obj->y) % MAX_Y; end commented code */ /* did this object move into a different subsector? */ subx = obj->x >> SUBPOWER; suby = obj->y >> SUBPOWER; if ((subx != tempx) || (suby != tempy)) { UN_Shift(subx, suby, obj); /* update sector lists */ } /* detect collisions */ xh = ((obj->x - SUBSIZE + 1) >> SUBPOWER); yh = ((obj->y - SUBSIZE + 1) >> SUBPOWER); for (txh=xh;txhshield<=0)) continue; /* can't collide with yourself or nonexistent things * / if (ttxh==txh) dx = obj->x - this_obj->x; else if (ttxhx - this_obj->x - (MAX_X); else dx = (MAX_X) + obj->x - this_obj->x; if (ttyh==tyh) dy = obj->y - this_obj->y; else if (ttyhy - this_obj->y - (MAX_Y); else dy = (MAX_Y) + obj->y - this_obj->y; if ( (dx < this_obj->bboxside) && (dx > obj->bboxside) && (dy < this_obj->bboxside) && (dy > obj_bboxside) /* BBOX COLLISION * / && (FE_DetectCollision(obj,this_obj)) ) /* we have a collision between obj and this_obj, so handle it */ { if ((this_obj->what == BULLET) || (obj->what == BULLET)) { if (this_obj->what == BULLET) { obj->shield -= this_obj->extra.bullet.damage; this_obj->shield = 0; AS_SetPic(this_obj->pic,EXPLODE); } if (obj->what == BULLET) { this_obj->shield -= obj->extra.bullet.damage; obj->shield = 0; AS_SetPic(obj->pic,EXPLODE); } } else if (obj->what <= SUPPLY)&& (obj->extra.animate.target == this_obj) { /* code to handle breeding, grabbing, etc. */ } else if (this_obj->what <= SUPPLY)&& (this_obj->extra.animate.target==obj) { /* same code with this_obj and obj reversed */ } else { /* objects bounce off of each other */ tempx = obj->velx * obj->mass; tempy = obj->vely * obj->mass; /* possible collision damage implementation: obj->shield -= ((this_obj->velx * this_obj->velx) + (this_obj->vely * this_obj->vely)) * this_obj->mass; this_obj->shield -= ((obj->velx * obj->velx) + (obj->vely * obj->vely)) * obj->mass; Alternate possibility: Calculate total kinetic energy as above, then recalculate after adjusting momentum, and subtract the difference from each of the colliders' shields (half each? proportional to mass?) */ obj->velx = (this_obj->velx * this_obj->mass) /obj->mass; obj->vely = (this_obj->vely * this_obj->mass) /obj->mass; this_obj->velx = tempx/this_obj->mass; this_obj->vely = tempy/this_obj->mass; } } this_obj=this_obj->next_hash; } } /* alternate collision detection deleted: too many bugs */ /* note about the place in the code of collision detection: I forsee problems: what if one object registers collision with obj2, and then when we're checking obj2 next, obj2 moves, and doesn't register collision with the original object anymore! Note from Adrian: I see this, and this isn't a problem. In fact, this is supposed to happen every time that a collision occurs, since it will prevent multiple "collisions" registering when only one collision occurred. We may want to skip UN_CheckObject() calls for UNMOVABLE objects, since if anything else can collide with them, they'll do so on their own UN_CheckObject() calls, and there is the possibility that an object might collide with an UNMOVABLE on its check, and again on the UNMOVABLE's check. */ /* the plan: subsectors are not overlapping, and of size SUBSIZE to check for collision, each object in the subsector is scanned, and if the coordinates overlap with the current object, we register a collision. We also need to check for boundary conditions; if we are on a subsector boundary, we also need to check for collision with objects in the bordering subsector. */ /* how does bounding box overlap work? imagine this is our box: .____ | | |____| The . is x,y. The other corners are: x + bboxside - 1, y x, y + bboxside - 1 x + bboxside - 1 , y + bboxside - 1 Why the - 1 in those coordinates? Because the bboxside measures the size of the bboxside: 0,1,2,3,4,5 is 6 numbers. If any other box is touching us, that means this 2nd box has top left coordinates within the outer big box: .____.____. | | | .____| | | | |____|____| (there's 3 boxes now: the box of the object we're checking for, the colliding box (2nd box), and the outer big box) How big is this outer box? That's dependent on the bboxside of the 2nd box. We'll call that bboxside, bbox2. We know the top left coordinates of the big box are: x - bbox2 + 1, y - bbox2 + 1 Why the + 1? Because the 2nd box needs to overlap. If we hadn't used the + 1s, the 2nd box might not overlap us, but instead be to the top left of the first box, by a margin of 1 pixel. So, if the coordinates of the 2nd box are within the large box, the 2nd box is colliding with the first box. Formally: Top left coordinates of the 1st box: x, y Top left coordinates of the 2nd box: x2, y2 if x2 => x - bbox2 + 1 AND x2 <= x + bboxside - 1 AND y2 => y - bbox2 + 1 AND y2 <= y + bboxside - 1 then there is collision this is equivalent to: if x2 > x - bbox2 AND x2 < x + bboxside AND y2 > y - bbox2 AND y2 < y + bboxside Of course this all may have been obvious to you already from the start, but it wasn't to me, that's why this extensive commenting: I was just thinking aloud. :) */ /* more code: */ void UN_Shift(long sectx, long secty, object *obj) {/* update sector lists */ /* first remove us from our old list */ if (obj->next_hash != NULL) { /* if there is a next object (note that you can ** avoid this check if the final object in any list is a ** special dummy object)(you only need one such object) */ (obj->next_hash)->prev_hash = obj->prev_hash; /* set next object to know who now points at it. */ } if (obj->prev_hash != NULL) { /* This is only for debugging! It *should* always be true. */ *(obj->prev_hash) = obj->next_hash; /* set the object that pointed to us to point to the object to which ** we pointed */ } else { /* ERROR CONDITION */ } /* now insert us at the start of the new list */ obj->prev_hash = &(sector[sectx][secty]); /* get who points to us */ obj->next_hash = sector[sectx][secty]; /* get who we point to */ sector[sectx][secty] = &obj; /* put ourself at sector list's start */ if (obj->next_hash != NULL) (obj->next_hash)->prev_hash = &(obj->next_hash); /* set next object's prev_hash to point to our next_hash pointer */ } void UN_InsertObject(long sectx, long secty, objects *obj) /* abbreviated form of UN_Shift(), used for inserting a new object that is ** already in the objects[] array into its sector[][] list; assumes that ** nothing critical is being pointed to only by obj->prev_hash or ** obj->next_hash */ { obj->prev_hash = &(sector[sectx][secty]); obj->next_hash = sector[sectx][secty]; sector[sectx][secty] = &obj; if (obj->next_hash != NULL) (obj->next_hash)->prev_hash = &(obj->next_hash); } void UN_InitTable() { int i; for (i=0;i<255;i++) { sin[i]=sin(i*360/256); cos[i]=cos(i*360/256); } } /* does anyone have a better way of doing this? Maybe UN_sin[] and UN_cos[] ** to avoid confusion with the 360 degree sin() and cos() ? */ void UN_InitSector() { /* TO BE CREATED */ /* needs: UN_ReSeed() */ } char UN_NewSector() { /* TO BE CREATED */ /* calls UN_InitSector() or returns to the current sector after a mid-game ** break, depending on the player's progress...this is where most of the ** between-action stuff will be */ } void UN_InitGame() { /* TO BE CREATED */ /* needs: UN_InitSector() */ } void UN_NewLife() { /* TO BE CREATED */ /* swaps a non-dead PLAYER object in the objects[] array for whatever is in ** objects[0] */ } void UN_ReSeed() { /* TO BE CREATED */ /* will have to adjust to make sure that not too many objects are in play at ** once...may even remove isolated inanimate objects (especially ASTEROIDS) ** if there are too many objects in play (for instance, during a dogfight ** with many BULLET/MISSILE objects being created) */ } char UN_PlayGame() { /* Will be called when a sector has been started, either after UN_InitGame() or by a game having been paused in mid sector, then unpaused */ long lasticks=FE_Set(); /* ticksper is set by FE_InitSystem, maybe it should be set by FE_Set() ** and reset by FE_Update(), like lasticks? */ while (1) { probes_exist=0; for (curobj=0;curobj0) UN_UpdateObject(objects[curobj]); if (objects[0]->shield<=0) { AS_PlayFX(FX_DIE); if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } /* UN_NewLife() returns 1 if no lives left for the player */ while (ticksper>FE_GetTicks(lasticks)) AI_DoQueue(); lasticks=FE_Update(objects[0]); /* syskeys that aren't handled below handled here */ if ((SYSKEYS)&4) FE_ToggleSound(); if ((SYSKEYS)&2) return 2; if ((SYSKEYS)&1) return MA_ConfirmQuit(2); if (!(probes_exist)) if (UN_NewSector()) return 1; /* we will probably want to change these conditions */ /* this would also be an ideal place to put a possible call to UN_ReSeed() if there are too few objects */ }} /* Return codes for UN_PlayGame: 0 = quitting, 1 = game over, 2 = paused */ /* I think that's all of it, but my terminal was losing some characters ** earlier...tell me if you see any glaring holes in the code, and I'll ** try to re-upload the lost piece. */ From undergrad.math.uwaterloo.ca!jmlait Mon May 29 20:55:42 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGIP0-000fJ5C; Mon, 29 May 95 20:55 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56995-1>; Mon, 29 May 1995 23:55:25 -0400 Date: Mon, 29 May 1995 23:55:20 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Debate continues... (fwd) In-Reply-To: <199505300322.UAA13741@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 29 May 1995, Adrian Tymes wrote: > > > I didn't see that you were breaking the within-subsector position into > > > fractional and integral parts. We'll need an extra two bits (maybe just > > > one?) to handle position overflow (aka: torriodal wraparound space), so > > > maybe we should start the within-subsector position at bit 23. This > > > could be considered by the fron end as 8.24 fixed point, and would solve the > > > accuracy problem. > > > > > ?? Again why? In case of position over flow, isn't the correct > > response to increment/decrement the subsect # based upon the carry, which > > is what this will do automagically in a 6:10:16 scheme? > > Remember: the universe.c part is in ANSI C, which can't read the carry/ > overflow bits, TMK. So we have to determine whether we increment/decrement > based on if x<0 or x>MAX_X, and similarly for y. This requires the extra > bit(s). > Ahh.. Finally, I think I see why we are having this whole arguement. The following question will probably allow confim what I think our disagreeance is over: If x<0 or x>MAX_X, WHAT DOES IT INCREMENT!!!! > UN_ReSeed() can probably do it faster, since it's going to be called anyway, > and this would be an ideal control parameter for it. > > We'll have to experiment with good safety margins based on average and peak > rates of fire, usual number of probes shooting at each other, and other > things that won't be known until after we get this program running, > regardless of how we handle objects[]. > Sounds damn complicated where a simpler solution will do. I'll defer to you on this one as it doesn't directly affect FE. > Hmm...actually, we may already be doing this approach. objects[] points to > all of the objects in existence, and they are only drawn if > objects[n].shield > 0 . > Again, I'll defer to your decision - I've said what I feel, but the final decision is up to the Universe as it's not an FE issue. > It is FE's responsibility to assign ticksper so that this never happens. > Different times between frames are a bad idea: the disruption between > frames will probably be perceived. If they are, then making universe > time based off of real time will be even worse: in the middle of a burst > of action, sudden 1-second (or even half-second) unexpected delays in the > animation can severely mess up the player's situation (I speak from > experience with programs that have done both of these, for instance > Descent on a low-memory 486/50 and Paradise Netrek over a lagged connection, > if you want to verify this). > > Trust me, if ticksper is high, the AI routines will probably evolve > deep-thinking probes on that machine. Processing that thought will > quickly use up the "leftover" cycles. So FE does not have to worry about > idle CPUs, but it does have to worry about keeping the frame rate constant. > But... It can't. The only way to ensure this is to take into account the worst case scenario, in which case it'll probably run at a sub optimum frame rate. I don't see a half second change, but a fluctuation of 50% is imaginable. I'm especially concerned with the planned SVGA version here... VGA is no problem (FE takes approxiamtely no time :>) After all, I prefer it dropping down to 5 fps in midst of a battle to it running at 5fps all the time... - Jeff Lait (SOL) From phil.ruu.nl!faassen Tue May 30 07:16:36 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGS5t-000fJNC; Tue, 30 May 95 07:16 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id QAA01867; Tue, 30 May 1995 16:16:15 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id QAA09582; Tue, 30 May 1995 16:15:08 +0200 From: Martijn Faassen Message-Id: <199505301415.QAA09582@laurel.stud.phil.ruu.nl> Subject: Reseeding To: ag-fe@krl.caltech.edu (fe), ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 30 May 1995 16:15:07 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 952 I've seen reseeding proposed to make sure of a constant rate of program execution. The idea would be to reseed the universe in such a way that there will be a constant amount of objects per subsector. >From an alife point of view, I don't really like the idea (or think it it feasible): - concentrations of food, eggs, probes, etc, are *interesting*. A disputed subsector with lots of new asteroids coming in, probes creating nests, swarms, a complex tiled large object built of smaller object tiles, and so on. So we shouldn't discourage them. - During a fight (which could happen anywhere in the battlefield), lots of bullets are going to fly around, asteroids may break into fragments, and so on. This means a sudden and large buildup of object concentration. So, I'd vote for another way to ensure the execution of the program is constant. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From mcl.ucsb.edu!uwingcat Tue May 30 10:26:28 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGV3h-000fJSC; Tue, 30 May 95 10:26 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id KAA29059; Tue, 30 May 1995 10:26:16 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id KAA15841; Tue, 30 May 1995 10:26:17 -0700 Message-Id: <199505301726.KAA15841@mcl.mcl.ucsb.edu> Subject: Reseeding (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 30 May 1995 10:26:17 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2136 Forwarded message: > From faassen@phil.ruu.nl Tue May 30 07:19 PDT 1995 > From: Martijn Faassen > Message-Id: <199505301415.QAA09582@laurel.stud.phil.ruu.nl> > Subject: Reseeding > To: ag-fe@krl.caltech.edu (fe), > ag-directors@alnilam.krl.caltech.edu (AG Directors) > Date: Tue, 30 May 1995 16:15:07 +0200 (MET DST) > X-Mailer: ELM [version 2.4 PL24] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 952 > > > I've seen reseeding proposed to make sure of a constant rate of program > execution. The idea would be to reseed the universe in such a way that there > will be a constant amount of objects per subsector. > > >From an alife point of view, I don't really like the idea (or think it > it feasible): > > - concentrations of food, eggs, probes, etc, are *interesting*. > A disputed subsector with lots of new asteroids coming in, probes > creating nests, swarms, a complex tiled large object built of smaller object > tiles, and so on. > > So we shouldn't discourage them. So we only get rid of objects that aren't near concentrations. > - During a fight (which could happen anywhere in the battlefield), lots of > bullets are going to fly around, asteroids may break into fragments, and > so on. This means a sudden and large buildup of object concentration. Thus, inanimate objects from elsewhere in the sector (and by themselves, of course) would be eliminated. > So, I'd vote for another way to ensure the execution of the program is > constant. How about: FE sets UN variables high enough so that, even when there are a lot of objects being drawn, the frame rate will be the same as when only the player is being drawn, and AI takes up any idle CPU cycles...on machines with many idle cycles, the probes evolve to take more cycles (and generate more complex probes) than on machines with few idle cycles (when complex probes would almost never be able to "think", would probably not react to much because of that, and would die off faster than simpler, less CPU-intensive probes). From mcl.ucsb.edu!uwingcat Tue May 30 10:33:15 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGVAF-000fJRC; Tue, 30 May 95 10:33 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id KAA00115; Tue, 30 May 1995 10:33:04 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id KAA17386; Tue, 30 May 1995 10:33:05 -0700 Message-Id: <199505301733.KAA17386@mcl.mcl.ucsb.edu> Subject: Re: Debate continues... (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 30 May 1995 10:33:05 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1342 > > Remember: the universe.c part is in ANSI C, which can't read the carry/ > > overflow bits, TMK. So we have to determine whether we increment/decrement > > based on if x<0 or x>MAX_X, and similarly for y. This requires the extra > > bit(s). > > > Ahh.. Finally, I think I see why we are having this whole > arguement. The following question will probably allow confim what I > think our disagreeance is over: > If x<0 or x>MAX_X, WHAT DOES IT INCREMENT!!!! if (x<0) x+=MAX_X; if (x>=MAX_X) x-=MAX_X; > > Trust me, if ticksper is high, the AI routines will probably evolve > > deep-thinking probes on that machine. Processing that thought will > > quickly use up the "leftover" cycles. So FE does not have to worry about > > idle CPUs, but it does have to worry about keeping the frame rate constant. > > > But... It can't. The only way to ensure this is to take into > account the worst case scenario, in which case it'll probably run at a > sub optimum frame rate. This is what I was suggesting, since "optimum" would be non-constant. Besides, FE controls how much time AI has for AI processes via ticksper and ticksleft, as you saw. So an "optimum" frame rate would almost never leave AI much time, while a "sub optimum" frame rate would allow for greater AI complexity. So we must balance FPS versus AI time. From undergrad.math.uwaterloo.ca!jmlait Tue May 30 11:07:38 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGVhX-000fJNC; Tue, 30 May 95 11:07 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57005-2>; Tue, 30 May 1995 14:07:03 -0400 Date: Tue, 30 May 1995 14:06:52 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Reseeding (fwd) In-Reply-To: <199505301726.KAA15841@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > A disputed subsector with lots of new asteroids coming in, probes > > creating nests, swarms, a complex tiled large object built of smaller object > > tiles, and so on. > > > > So we shouldn't discourage them. > > So we only get rid of objects that aren't near concentrations. > I would say this is as vague a statement as saying get rid of objects at concentrations. I can't see off hand how you would perform either without resulting in a slow garbage collection style routine. In other words, why even bother with this issue? Why not just run a simple heap based method? > > So, I'd vote for another way to ensure the execution of the program is > > constant. > > How about: FE sets UN variables high enough so that, even when there are > a lot of objects being drawn, the frame rate will be the same as when > only the player is being drawn, and AI takes up any idle CPU cycles...on > machines with many idle cycles, the probes evolve to take more cycles (and > generate more complex probes) than on machines with few idle cycles (when > complex probes would almost never be able to "think", would probably not > react to much because of that, and would die off faster than simpler, > less CPU-intensive probes). > What I said earlier: I'd rather play a game which drops to 5fps in a battle than one which runs at 5fps all the time. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Tue May 30 11:19:21 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGVsp-000fJNC; Tue, 30 May 95 11:19 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57009-3>; Tue, 30 May 1995 14:18:57 -0400 Date: Tue, 30 May 1995 14:18:50 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Debate continues... (fwd) In-Reply-To: <199505301733.KAA17386@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 30 May 1995, Adrian Tymes wrote: > > > Remember: the universe.c part is in ANSI C, which can't read the carry/ > > > overflow bits, TMK. So we have to determine whether we increment/decrement > > > based on if x<0 or x>MAX_X, and similarly for y. This requires the extra > > > bit(s). > > > > > Ahh.. Finally, I think I see why we are having this whole > > arguement. The following question will probably allow confim what I > > think our disagreeance is over: > > If x<0 or x>MAX_X, WHAT DOES IT INCREMENT!!!! > > if (x<0) x+=MAX_X; > if (x>=MAX_X) x-=MAX_X; > It is as I thought. That is an entirely unnecessary calculation as with the proposed system the natural wrap at +/- 2billion will do that automagically. If you want wrap earlier, hey, just & off the right number of bits. Therefore, one does not need the sign/overflow bits, and can live doing a 6:10:16 format. > > But... It can't. The only way to ensure this is to take into > > account the worst case scenario, in which case it'll probably run at a > > sub optimum frame rate. > > This is what I was suggesting, since "optimum" would be non-constant. > Besides, FE controls how much time AI has for AI processes via ticksper > and ticksleft, as you saw. So an "optimum" frame rate would almost never > leave AI much time, while a "sub optimum" frame rate would allow for > greater AI complexity. So we must balance FPS versus AI time. > Perhaps I didn't explain my side properly there... I realize that A-Life will be taking a good portion of the time regardless, my point is that I'd rather have it playing at 70 fps than 35. (70 fps would involve 2/3 of processor time going to alife/universe on my machine). The thing is, in order to ensure we can ALWAYS draw the screen in one frame, we'll have to have it a lot lower than it can usually handle, ie: fix it at 15 fps when it can usually run four times as fast with little penalty to a-life. In SVGA it would be even worse, as the `fastest' frame rates will be much slower. Your approach seems to have the game run at a constant frame rate no matter what, while as I, when I play games, prefer that they adjust their speed. Ever played Doom on a slow computer? I find the frame rates rather variable, but I'd rather be running at a faster speed 50% of the time than always run at the lower speed. We aren't talking 1 or even .5 second pauses like you mentioned with Descent on a network - we're talking .1 or .05 glitches. - Jeff Lait (SOL) From charles Tue May 30 12:10:36 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGWgU-000fJ6C; Tue, 30 May 95 12:10 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA06285; Tue, 30 May 1995 12:11:00 -0700 Message-Id: <9505301911.AA06285@altair.krl.caltech.edu> Subject: Re: Reseeding To: jmlait@undergrad.math.uwaterloo.ca (Jeff Lait) Date: Tue, 30 May 1995 12:11:00 -0800 (PDT) From: "Splinterwood" Cc: ag-universe, ag-fe, ag-directors In-Reply-To: from "Jeff Lait" at May 30, 95 02:53:11 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1979 > How's this sound? We give the AL an amount of time directly > proportional to how much time the FE/UN takes. As a random figure (Probably > would be user configurable) we could give the AL code 60% of the > processor time. To do this, after Universe & FE have finished their > updates, we see how long they took. Then, we take 1.5 times that > and give that much time for AL to perform their actions. The > displacements of all objects is then calculated based upon the total > time. Sounds perfect. We can even put the 1.5 as a configurable so that if the player think thier machine needs more or less time to make the game playable, they can alter that. Damn, we're going to need good documentation on this... > This way, in any second, regardless of how many/few frames are > drawn, .6 of that second will be spent by the AL routines. I don't think > giving them that extra sensor would help overmuch, probably just confuse > the issus farther. Ther sensor is useless unless the amount of time a creature gets per second is variable. > > My recomendation on how to combat this refresh problem (which I have no > > idea if it will work) is to give each object a priority according to their > > velocity, the type of object they are, and their interactions with other > > objects. Thus if we have a stationary asteroid, it can just sit still > > (until something interacts with it) and we don't have to worry about it, > > while if we have a ship which is flying all over the place at taking lots > > of hits and whatnot, it gets refreshed a lot. If we do it right, then > > in a space battle, some of the background materials might begin to look > > real choppy, but hopefully we can get the ships and bullets to looks > > slightly smoother for it. > > Interesting idea.... Don't see how it could apply to FE's area, > but UN could possible do something like this to update certain objects > only every so many frames. Agreed. --- Charles From mcl.ucsb.edu!uwingcat Tue May 30 14:05:45 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGYTs-000fJ6C; Tue, 30 May 95 14:05 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id OAA00633; Tue, 30 May 1995 14:05:29 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id OAA20235; Tue, 30 May 1995 14:05:30 -0700 Message-Id: <199505302105.OAA20235@mcl.mcl.ucsb.edu> Subject: Re: Reseeding (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 30 May 1995 14:05:30 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3022 > > > So we only get rid of objects that aren't near concentrations. > > > > > I would say this is as vague a statement as saying get rid of > > objects at concentrations. I can't see off hand how you would perform > > either without resulting in a slow garbage collection style routine. In > > other words, why even bother with this issue? Why not just run a simple > > heap based method? > > I think we should work with a thresholding system; We'll have a minimum > number of creatures for the game to remain fun, and a maximum number for > the game to remain playable. These can even be configurable with > recomendation settings for different machines. If either of these > thresholds are passed, we randomly insert or remove creatures as needed. Hmm...this could work. And if we allocate a certain amount of memory at the beginning of the game (enough so that we probably won't surpass it), and only start doing mid-game mallocs if that amount is passed, that'll probably solve all of the proposed problems. I'll put it in as soon as I log off. > Also, for what its worth, concentrations are not all that hard to detect. > There are a number of simple algorithms which take in coordinate pairs and > can return a relative number for the concentration at any point. Can you forward some of these algorithms to ag-universe, please? > I agree with Jeff here, plus I don't like the idea of the AL's not getting > a constant amount of time per second. What that would mean is that they > won't be able to act as well when the action gets heavy, and they need to > react the most. If we do end up varying the time given to them, then we > should at least give them an extra sensor so they know how much CPU time > they have, and can adjust the complexity of their algorithms accordingly. Would passing ticksper and ticksleft to AI_DoQueue() suffice? > My recomendation on how to combat this refresh problem (which I have no > idea if it will work) is to give each object a priority according to their > velocity, the type of object they are, and their interactions with other > objects. Thus if we have a stationary asteroid, it can just sit still > (until something interacts with it) and we don't have to worry about it, > while if we have a ship which is flying all over the place at taking lots > of hits and whatnot, it gets refreshed a lot. If we do it right, then > in a space battle, some of the background materials might begin to look > real choppy, but hopefully we can get the ships and bullets to looks > slightly smoother for it. This is what we already do with inanimate objects: check to see if anything interacts with (ie, collides) with it after moving it (if it is moving), and if nothing interacts with it, then ignore it. If you mean to skip UN_CheckObject() entirely, then a problem could occur if a moving asteroid intersects the path of a probe, but because it wasn't updated during that frame, it hasn't been moved to the intersection point, and no collision occurs. From mcl.ucsb.edu!uwingcat Tue May 30 14:27:48 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGYpF-000fJ6C; Tue, 30 May 95 14:27 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id OAA03623; Tue, 30 May 1995 14:27:37 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id OAA26804; Tue, 30 May 1995 14:27:38 -0700 Message-Id: <199505302127.OAA26804@mcl.mcl.ucsb.edu> Subject: Re: Debate continues... (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 30 May 1995 14:27:38 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 977 > > > > Remember: the universe.c part is in ANSI C, which can't read the carry/ > > > > overflow bits, TMK. So we have to determine whether we increment/decrement > > > > based on if x<0 or x>MAX_X, and similarly for y. This requires the extra > > > > bit(s). > > > > if (x<0) x+=MAX_X; > > if (x>=MAX_X) x-=MAX_X; > > > It is as I thought. That is an entirely unnecessary calculation > as with the proposed system the natural wrap at +/- 2billion will do that > automagically. If you want wrap earlier, hey, just & off the right > number of bits. Therefore, one does not need the sign/overflow bits, and > can live doing a 6:10:16 format. This is not part of the ANSI C specification, therefore universe.c can not rely on it unless *all* of the FE compilers that are or will be used on this project ignore overflow. > Perhaps I didn't explain my side properly there... [etc.] So am I the only one that doesn't like variable FPS? If so, I'll put time in... From mcl.ucsb.edu!uwingcat Tue May 30 14:34:02 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGYvG-000fJ9C; Tue, 30 May 95 14:33 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id OAA04515; Tue, 30 May 1995 14:33:47 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id OAA28630; Tue, 30 May 1995 14:33:48 -0700 Message-Id: <199505302133.OAA28630@mcl.mcl.ucsb.edu> Subject: bounding box size To: ag-universe@krl.caltech.edu Date: Tue, 30 May 1995 14:33:48 -0700 (PDT) Cc: ag-directors@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 677 Would it be a good idea to make all of the objects have the same bounding box size, rather than specify it for each object? This would result in more calls to FE_DetectCollision(), but it would cut at least two indirect references per collision, and it would avoid one possible problem that I noticed: if a small object moves into a large object's bbox during the small object's UN_CheckObject(), but doesn't collide because the large object's corner is outside of the small object's bbox, then the large object moves away during its UN_CheckObject() (which may be before or after the next screen refresh), then no collision will be registered under the current system. From undergrad.math.uwaterloo.ca!jmlait Tue May 30 14:51:48 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGZCM-000fJ6C; Tue, 30 May 95 14:51 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56999-2>; Tue, 30 May 1995 17:51:11 -0400 Date: Tue, 30 May 1995 17:50:55 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Debate continues... (fwd) In-Reply-To: <199505302127.OAA26804@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 30 May 1995, Adrian Tymes wrote: > > It is as I thought. That is an entirely unnecessary calculation > > as with the proposed system the natural wrap at +/- 2billion will do that > > automagically. If you want wrap earlier, hey, just & off the right > > number of bits. Therefore, one does not need the sign/overflow bits, and > > can live doing a 6:10:16 format. > > This is not part of the ANSI C specification, therefore universe.c can not > rely on it unless *all* of the FE compilers that are or will be used on > this project ignore overflow. > Damn... Forgot about the finer points of portability... To think ANSI C includes Duff Devices but not standardized overflow... In this case you are write - you do need one bit extra to ensure the compiler can avoid overflow. I'd suggest you & off the 31 desired bits rather than the if <, if > construct. So where do we pull the bit of precision from? The subsector or the index? I'd vote for the subsector, making the new setup: 33222222222211111111110000000000 10987654321098765432109876543210 || || || | || || |+-------+------+ || |+---+---+ +--------- Fractional pixel position. |+-+--+ +---------------------- Integral pixel position (0-511) | +------------------------------ Subsector number (0-63) +--------------------------------- Prevent overflow... With the fractional component to the pixel position the loss of a bit of precision will probably be unnoticed. > > Perhaps I didn't explain my side properly there... > > [etc.] > > So am I the only one that doesn't like variable FPS? If so, I'll put time > in... > Well... you know my vote :> - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Tue May 30 15:35:52 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGZt7-000fJ5C; Tue, 30 May 95 15:35 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57014-3>; Tue, 30 May 1995 18:35:23 -0400 Date: Tue, 30 May 1995 18:34:45 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-universe@krl.caltech.edu, ag-directors@krl.caltech.edu Subject: Re: bounding box size In-Reply-To: <199505302133.OAA28630@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 30 May 1995, Adrian Tymes wrote: > Would it be a good idea to make all of the objects have the same bounding > box size, rather than specify it for each object? This would result > in more calls to FE_DetectCollision(), but it would cut at least two > indirect references per collision, and it would avoid one possible problem > that I noticed: if a small object moves into a large object's bbox during > the small object's UN_CheckObject(), but doesn't collide because the > large object's corner is outside of the small object's bbox, then the > large object moves away during its UN_CheckObject() (which may be before > or after the next screen refresh), then no collision will be registered > under the current system. > Just took a look at the bounding box check. Exclusive rectangles? Argh... :> Anyways, what you are doing is basically the following, no? if (x2 + w2 > x1) && (x2 < x1 + w1) && (y2 + h2 > y1) && (y2 < y1 + h1) I would claim that this does not have the error you specify. If the two bounding boxes overlap, it will detect it. Look at it this way: how would you go about finding the intersection of the two boxes: nX = max(x1, x2) nY = max(y1, y2) nW = min((x1 + w1) - nX, (x2 + w2) - nX) nH = min((y1 + h1) - nY, (y2 + h2) - nY) If nW and nH are both positive, an intersection exists which is specified in the usual way by nx, ny, nw, nh. Or, we are trying to see if: min(x1+w1, x2+w2) > nX and min(y1+h1, y2+h2) > nY But as we are looking at the minimum, if it is true for the minimum it is true for both, so this is also valid: x1 + w1 > nx && x2 + w2 > nx y1 + h1 > ny && y2 + h2 > ny Now nx & ny are the maximums of x1,x2 and y1,y2 respectively. It is also clear if nx = x1, the first eq'n is true, so we only need to test it for x2. Furthermore, as it's the maximum we know if it holds for the max, it will hold for both. Similar things hold for the rest, leaving: x1 + w1 > x2 && x2 + w2 > x1 y1 + h1 > y2 && y2 + h2 > y1 Which, glancing up, is exactly what we have. So where is the error in this derivation which will cause a small object to miss a larger one? As far as I can tell, the mentioned scenario will not result in a missed collision. I would think reducing calls to FE_DetectCollision (Which likely uses circular detection would more than make up for any extra time from the extra references. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Tue May 30 17:22:20 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGbY8-000fJ5C; Tue, 30 May 95 17:22 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57009-1>; Tue, 30 May 1995 20:22:02 -0400 Date: Tue, 30 May 1995 20:21:52 -0400 From: Jeff Lait To: Directors Subject: universe.h Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello... I was scanning though my archives and the archives at the ftp site for some form of universe.h file (A file definining what functions/structures/definitions/variables are exported). The only thing I could find was some form of amalgamation of FE, ALife, and a little bit of UN. So could someone post a h file which I can use in POC IV?? - Jeff Lait (SOL) From phil.ruu.nl!faassen Wed May 31 08:28:32 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGph7-000fJ6C; Wed, 31 May 95 08:28 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id RAA01026 for ; Wed, 31 May 1995 17:28:08 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id RAA03431 for ag-directors@alnilam.krl.caltech.edu; Wed, 31 May 1995 17:28:05 +0200 From: Martijn Faassen Message-Id: <199505311528.RAA03431@laurel.stud.phil.ruu.nl> Subject: POC3 To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Wed, 31 May 1995 17:28:04 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1334 Jeff (and everybody else in the directors), Thanks for POC3, it looks very nice! Fast (at least on my new DX100 :). Some comments: when moving slow stars appear to wiggle. Is this because they're only moving in horizonal and vertical directions, not diagonal directly? (haven't checked the code on that) Keys: Except for a max speed, the moving seems good. (much better than POC1 :) It's not hard to steer your way around, it seems. (though I haven't tried any obstacle course yet). The brake key (as you probably know) has a different effect than intended by universe (this one is basically a full stop, universe is simply backwards thrust). POC3 is of course bare bones now, but as soon as we get Universe plugged in (especially collision detection stuff), and Art Sound creates nice pictures for the sprites, I think it'll look quite good. Which reminds me: Sprite animation protocol. Art-sound creates the sprites, that much is obvious. Who is doing the animation? FE or Universe? We would assume Universe, as animation can be pretty platform independent. But, then we'll need to work out a protocol, to enable universe to simply start an animation and then to stop bothering about it (until it is finished). Any ideas, anyone? Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From mcl.ucsb.edu!uwingcat Wed May 31 09:34:54 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGqjK-000fJ6C; Wed, 31 May 95 09:34 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id JAA28512 for ; Wed, 31 May 1995 09:34:35 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id JAA03995; Wed, 31 May 1995 09:34:27 -0700 Message-Id: <199505311634.JAA03995@mcl.mcl.ucsb.edu> Subject: universe.h (fwd) To: ag-directors@krl.caltech.edu Date: Wed, 31 May 1995 09:34:27 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 593 > Hello... I was scanning though my archives and the archives at > the ftp site for some form of universe.h file (A file definining what > functions/structures/definitions/variables are exported). The only thing > I could find was some form of amalgamation of FE, ALife, and a little bit > of UN. So could someone post a h file which I can use in POC IV?? Umm...why don't we put of a list of the global variables & prototypes of the functions that each group uses and calls (outside of purely internal functions, of course)? You can then concatenate them into the next universe.h . From mcl.ucsb.edu!uwingcat Wed May 31 09:53:50 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGr1Z-000fJ9C; Wed, 31 May 95 09:53 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id JAA01416; Wed, 31 May 1995 09:53:30 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id JAA07858; Wed, 31 May 1995 09:53:25 -0700 Message-Id: <199505311653.JAA07858@mcl.mcl.ucsb.edu> Subject: Re: Debate continues... (fwd) To: ag-directors@krl.caltech.edu Date: Wed, 31 May 1995 09:53:25 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1261 > I'd suggest you & off the 31 desired bits > rather than the if <, if > construct. So where do we pull the bit of > precision from? The subsector or the index? I'd vote for the subsector, > making the new setup: > 33222222222211111111110000000000 > 10987654321098765432109876543210 > || || || | > || || |+-------+------+ > || |+---+---+ +--------- Fractional pixel position. > |+-+--+ +---------------------- Integral pixel position (0-511) > | +------------------------------ Subsector number (0-63) > +--------------------------------- Prevent overflow... > > With the fractional component to the pixel position the loss of a > bit of precision will probably be unnoticed. Waitaminute...we're doing 512 pixels per subsector? I thought that we were doing approx. 11 * 15 subsectors on the screen. Remember that an object can be as large as an entire subsector...can you really handle 512*512 sprites? I'll put this into the next universe.c . Remember that you can put the point anywhere you want, since universe.c thinks that it is dealing with an integer (and doesn't differentiate between the subsector and within-subsector parts of x and y when dealing with the within-subsector parts). From undergrad.math.uwaterloo.ca!jmlait Wed May 31 11:49:13 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGspJ-000fJ9C; Wed, 31 May 95 11:49 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56944-3>; Wed, 31 May 1995 14:48:43 -0400 Date: Wed, 31 May 1995 14:48:31 -0400 From: Jeff Lait To: Martijn Faassen cc: AG Directors Subject: Re: POC3 In-Reply-To: <199505311528.RAA03431@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 31 May 1995, Martijn Faassen wrote: > Some comments: > > when moving slow stars appear to wiggle. Is this because they're only > moving in horizonal and vertical directions, not diagonal directly? > (haven't checked the code on that) Actually, this is because we are running at the oh so detailed 320x200 :> As a result, in order to move diagonally at a very slow speed they first move to the left one frame when the counter overflows, and then move up in another frame (Possible a long time away). There is nothing preventing them from doing both simultaneously except for the fact that the error had overflowed in horizontal before vertical. If we were running on a much higher resolution, this aliasing would not be noticable. > Keys: > > Except for a max speed, the moving seems good. (much better than POC1 :) > It's not hard to steer your way around, it seems. (though I haven't tried > any obstacle course yet). The brake key (as you probably know) has a > different effect than intended by universe (this one is basically a full > stop, universe is simply backwards thrust). > Har... Yeah, I realized how the backwards thrust was supposed to work, but when I was bug hunting I wanted a way to make sure I was stopped. I agree with the comment re: poc1. Way easier to control. I personally think it's the stars that provide most of that appearance. > POC3 is of course bare bones now, but as soon as we get Universe plugged > in (especially collision detection stuff), and Art Sound creates nice > pictures for the sprites, I think it'll look quite good. > Yep... Incidentally: If we do the shield effect for the ships FE will probably want something in the object field dealing with current shield visibility status (Remember the idea was to flash the shields when they are hit and have them fade out...) > Which reminds me: > > Sprite animation protocol. Art-sound creates the sprites, that much is obvious. > Who is doing the animation? FE or Universe? We would assume Universe, as > animation can be pretty platform independent. But, then we'll need to work > out a protocol, to enable universe to simply start an animation and then to > stop bothering about it (until it is finished). Any ideas, anyone? Universe, I believe. FE just needs to have the current picture pointer correctly set. Though note that Universe can't know how the sprites are stored in memory - current implementation of FE has sets of 4 sprites placed side by side... - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed May 31 11:54:22 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGsu6-000fJ7C; Wed, 31 May 95 11:54 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57011-1>; Wed, 31 May 1995 14:53:34 -0400 Date: Wed, 31 May 1995 14:53:23 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Debate continues... (fwd) In-Reply-To: <199505311653.JAA07858@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 31 May 1995, Adrian Tymes wrote: > > I'd suggest you & off the 31 desired bits > > rather than the if <, if > construct. So where do we pull the bit of > > precision from? The subsector or the index? I'd vote for the subsector, > > making the new setup: > > 33222222222211111111110000000000 > > 10987654321098765432109876543210 > > || || || | > > || || |+-------+------+ > > || |+---+---+ +--------- Fractional pixel position. > > |+-+--+ +---------------------- Integral pixel position (0-511) > > | +------------------------------ Subsector number (0-63) > > +--------------------------------- Prevent overflow... > > > > With the fractional component to the pixel position the loss of a > > bit of precision will probably be unnoticed. > > Waitaminute...we're doing 512 pixels per subsector? I thought that we were > doing approx. 11 * 15 subsectors on the screen. Remember that an object > can be as large as an entire subsector...can you really handle 512*512 sprites? > Ahh.. But FE does not have to worry about 512 sprites. if their are that many subsectors on the screen we couldn't even have 32x32 sprites! 200/15 = 40/3 = ~13 pixel sprites being the maximum with 15 subsectors high per screen!!!! > I'll put this into the next universe.c . Remember that you can put the > point anywhere you want, since universe.c thinks that it is dealing with > an integer (and doesn't differentiate between the subsector and > within-subsector parts of x and y when dealing with the within-subsector > parts). Pretty much the same with FE. We already know what subsector they are in from their existance in the given list. Just need to know range of the fractional part. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed May 31 11:56:49 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGswg-000fJ8C; Wed, 31 May 95 11:56 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56950-3>; Wed, 31 May 1995 14:56:21 -0400 Date: Wed, 31 May 1995 14:56:10 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Re: universe.h (fwd) In-Reply-To: <199505311634.JAA03995@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 31 May 1995, Adrian Tymes wrote: > > Hello... I was scanning though my archives and the archives at > > the ftp site for some form of universe.h file (A file definining what > > functions/structures/definitions/variables are exported). The only thing > > I could find was some form of amalgamation of FE, ALife, and a little bit > > of UN. So could someone post a h file which I can use in POC IV?? > > Umm...why don't we put of a list of the global variables & prototypes of the > functions that each group uses and calls (outside of purely internal > functions, of course)? You can then concatenate them into the next > universe.h . > I presume that `of' should be interpretted as `out' :> I don't think everything should be concatenated into one universe.h as has beenn done in the past, however. I think we should have a distinct fe.h, universe.h, alife.h, each having the exports of that group. Universe will probably just import them all, but this allows fe to ignore the alife stuff etc. Also, it makes it cleaner in the end. So, what is the current universe.h and where is it??? - Jeff Lait (SOL) From phil.ruu.nl!faassen Wed May 31 14:54:11 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sGviF-000fJ7C; Wed, 31 May 95 14:54 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id XAA08600 for ; Wed, 31 May 1995 23:53:47 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id XAA09015 for ag-directors@alnilam.krl.caltech.edu; Wed, 31 May 1995 23:53:43 +0200 From: Martijn Faassen Message-Id: <199505312153.XAA09015@laurel.stud.phil.ruu.nl> Subject: The Future To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Wed, 31 May 1995 23:53:42 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4568 Hello everybody, Since we all need to know what's going on and what's going to happen next once in a while, here is a general plan on how to continue from here. Tell us what you all think! ----------------- Where are we now? ----------------- The Universe group has decided on the general 'physics' of the Universe, and coding is well underway. Some plot things need to be decided, and we are still developing 'evolving' weapons, but the main thing is there. It is in need of more coders to create the 'engine' for the game itself. Jeff Lait's POC 3 should give a clear head start on this engine, which the Universe can build upon. The Alife group has now a quite detailed description of the Behaviour Code of the probes, and is currently delving into implementation issues; implementation itself will not be long off. The PC Front End group is working on code to display everything Universe needs to have displayed. The abstract part of this work should be shifted over to the new ag-fe group for general front end discussion. The Mac Front End group is waiting for ag-pcx, ag-fe, and ag-universe to finished the specifications, so that they can start coding as well. The Art/Sound group is working on evolving art and music, as well as the plot movies for the game. But is waiting for the other groups to figure out what plot they want to have before any major work begins. Meanwhile, evolving sprites can be worked on, as well as an animation protocol for those sprites (in cooperation with FE and Universe). Furthermore, we have WWW pages, an FAQ, and an FTP archive, thanks to Charles and many other contributers. -------- The plan -------- This is an open project, so there is no reason why some groups can't take advantage of some 'fresh blood', in fact most groups could use some new people to help with their sections and add fresh ideas to the discussions. The various group coordinators have been asked to write up a list of requirements they have for people who'd like to join their group. We can then post announcements to various newsgroups, asking if anyone is interesting in joining in (with references on where to find our FAQ and WWW pages). Now that our WWW page is up and lookin' good, we can point newcomers to that and the FAQ to bring them up to speed fast! Additions to the FAQ and WWW page can be sent to Charles (charles@krl.caltech.edu). Also, some of the people in our various groups are very active and have much input on the discussion, and coding. If you want to nominate any such person to the directors group, please go ahead and tell us why! Anyone who's proven him or herself and wants to, should be able to join the coordinators discussion. (as this is a freeware project, and it seems only fair that people who do a lot, can have more responsibility and influence as well - if they want to have it :) In conjunction with this, we are changing the titles of the 'directors' to 'coordinators', as it more clearly states their position. The directors group will still be titled the ag-directors, as it is the directing force behind the project. But it will now be accepting not only the group coordinators, but other who wish to put out the extra effort required by being on the directors list. ------------------------- Leadership Reorganization ------------------------- Besides changing the title of the directors to coordinators, the group leadership is going through reorganization as well. The main change is that the 'general director' position is being eliminated from the leadership structure. The directors group will take this role upon itself as a group, to guide the future of the project. If it becomes necessary that the project requires a single general director again, the directors group will promote one of their own to that position. The other remaining leadership positions still remain intact through the reorganization, but we are /still/ looking for a coordinator for the 'sound' portion of the art/sound group, so any volunteers are encouraged to step forward. ---------------- General Progress ---------------- We hope to have a Universe/PCFE alpha up soon, like in a few weeks. The alife alpha should follow somewhere in late June (yes, we take our time - we do want to run hundreds of parse trees in a language we've designed ourselves concurrently, not an easy job :) After that, we'll look further. On to beta stage! :) Martijn, Charles & Greg -- Martijn Faassen email:faassen@phil.ruu.nl From charles Thu Jun 1 13:53:12 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sHHE8-000fJ5C; Thu, 1 Jun 95 13:52 PDT Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA14281; Thu, 1 Jun 1995 13:52:33 -0700 Message-Id: <9506012052.AA14281@rigel.krl.caltech.edu> Subject: A couple of things... To: ag-directors Date: Thu, 1 Jun 1995 13:52:32 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 677 Greetings folks, First, I'd just like to mention a bit about the archives; The ones found on the web page have to be updated from the ones at the ftp site, so they will typically be a day or two behind. I have a shell script for updating them which I'll stick in the cron table as soon. In the mean-time, if you need a perfectly up to date archive, the ftp site is updated as the letters come in. Please let me know if there are any problems with it. Also, I'd like to nominate I. Badcoe to join the directors group; he's been invaluable in the ag-alife subgroup, and Martijn will vouce for the huge amount of work he's put in. Should be it for now... --- Charles From galaxy.csc.calpoly.edu!gtaylor Thu Jun 1 16:36:08 1995 Return-Path: Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sHJmO-000fJ5C; Thu, 1 Jun 95 16:35 PDT Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.11/8.6.11) id QAA08639; Thu, 1 Jun 1995 16:37:46 -0700 Date: Thu, 1 Jun 1995 16:37:46 -0700 (PDT) From: Greg Taylor To: ag-directors@krl.caltech.edu Subject: Re: A couple of things... In-Reply-To: <9506012052.AA14281@rigel.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Also, I'd like to nominate I. Badcoe to join the directors group; > he's been invaluable in the ag-alife subgroup, and Martijn will vouce for > the huge amount of work he's put in. Sure! I vote for I. Badcoe's presence in the directors group. What about Keith Wiley as our Art-Sound rep? -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - Greg - gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we - = Taylor - gtaylor@oboe.aix.calpoly.edu - go, 'Ere wo go, = - _________ - woodowl!taylor@lll-winken.llnl.gov - WAAAARRRRRRGGGGG!!!! - = / _ / ------------------------------------------------------------= - /___/ / - My WubbaWubbaWubba page : http://www.calpoly.edu/~gtaylor - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From charles Thu Jun 1 16:40:39 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sHJqu-000fJ5C; Thu, 1 Jun 95 16:40 PDT Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA14968; Thu, 1 Jun 1995 16:40:45 -0700 Message-Id: <9506012340.AA14968@rigel.krl.caltech.edu> Subject: Re: A couple of things... To: gtaylor@galaxy.csc.calpoly.edu (Greg Taylor) Date: Thu, 1 Jun 1995 16:40:44 -0800 (PDT) From: "Splinterwood" Cc: ag-directors In-Reply-To: from "Greg Taylor" at Jun 1, 95 04:37:46 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 434 > > Also, I'd like to nominate I. Badcoe to join the directors group; > > he's been invaluable in the ag-alife subgroup, and Martijn will vouce for > > the huge amount of work he's put in. > > Sure! I vote for I. Badcoe's presence in the directors group. What > about Keith Wiley as our Art-Sound rep? I actually just sent an E-Mail to Jeff asking him what he thought of that. :-) Sounds good to me however. --- Charles From undergrad.math.uwaterloo.ca!jmlait Thu Jun 1 18:22:49 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sHLRl-000fJ5C; Thu, 1 Jun 95 18:22 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57025-3>; Thu, 1 Jun 1995 21:22:17 -0400 Date: Thu, 1 Jun 1995 21:22:11 -0400 From: Jeff Lait To: Splinterwood cc: Greg Taylor , ag-directors@krl.caltech.edu Subject: Re: A couple of things... In-Reply-To: <9506012340.AA14968@rigel.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 1 Jun 1995, Splinterwood wrote: > > > Also, I'd like to nominate I. Badcoe to join the directors group; > > > he's been invaluable in the ag-alife subgroup, and Martijn will vouce for > > > the huge amount of work he's put in. > > > > Sure! I vote for I. Badcoe's presence in the directors group. What > > about Keith Wiley as our Art-Sound rep? > > I actually just sent an E-Mail to Jeff asking him what he thought of that. :-) > Sounds good to me however. > And it also sounds like a good idea to me. I wouldn't mind at all handing it over to Keith. As we all seem to agree to this, I'll email Keith to see what he thinks of the position. - Jeff Lait (SOL) From mcl.ucsb.edu!uwingcat Fri Jun 2 15:38:09 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sHfLw-000fJ5C; Fri, 2 Jun 95 15:38 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id PAA11025 for ; Fri, 2 Jun 1995 15:37:43 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id PAA16717; Fri, 2 Jun 1995 15:37:41 -0700 Message-Id: <199506022237.PAA16717@mcl.mcl.ucsb.edu> Subject: A couple of things... (fwd) To: ag-directors@krl.caltech.edu Date: Fri, 2 Jun 1995 15:37:41 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 340 > Also, I'd like to nominate I. Badcoe to join the directors group; > he's been invaluable in the ag-alife subgroup, and Martijn will vouce for > the huge amount of work he's put in. I'll vouch for the additional work that he has put in on the ag-universe subgroup (especially coming up with the initial collision detection algorithm). From charles Fri Jun 2 15:47:57 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sHfVO-000fJ6C; Fri, 2 Jun 95 15:47 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA05080; Fri, 2 Jun 1995 15:48:06 -0700 Message-Id: <9506022248.AA05080@altair.krl.caltech.edu> Subject: Badcoe... To: ag-directors Date: Fri, 2 Jun 1995 15:48:06 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 111 It seems pretty unanimous to having him join the group, so I'm going to offer it to him now. --- Charles From post.demon.co.uk!darkin.demon.co.uk!Christian Sat Jun 3 03:49:54 1995 Return-Path: <@post.demon.co.uk:Christian@darkin.demon.co.uk> Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sHqm4-000fJ5C; Sat, 3 Jun 95 03:49 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id aa23305; 3 Jun 95 11:44 +0100 Received: from darkin.demon.co.uk by post.demon.co.uk id aa22922; 3 Jun 95 11:44 +0100 Date: Sat, 3 Jun 1995 08:30:33 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <213@darkin.demon.co.uk> To: ag-directors@alnilam.krl.caltech.edu Subject: Re: A couple of things... (fwd) X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 12 In your message dated Friday 2, June 1995 you wrote : > > Also, I'd like to nominate I. Badcoe to join the directors group; > > he's been invaluable in the ag-alife subgroup, and Martijn will vouce for > > the huge amount of work he's put in. Absolutely. :D -- Christian Darkin From charles Sat Jun 3 20:42:44 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sI6aC-000fJ5C; Sat, 3 Jun 95 20:42 PDT Sender: charles (Charles Ofria) Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA11734; Sat, 3 Jun 1995 20:42:49 -0700 Message-Id: <9506040342.AA11734@altair.krl.caltech.edu> Subject: Another WWW update... To: cs323093@student.uq.edu.au (Andy) Date: Sat, 3 Jun 1995 20:42:32 -0800 (PDT) From: "Splinterwood" In-Reply-To: from "Andy" at Jun 4, 95 11:32:42 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 161 Sender: charles Thanx to Andy Payne, we have another gif at the ftp site. This one is located at the top of the alife page; a close up of one type of probe. --- Charles From charles Mon Jun 5 12:49:54 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIi9Q-000fJ5C; Mon, 5 Jun 95 12:49 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA19027; Mon, 5 Jun 1995 12:49:35 -0700 Message-Id: <9506051949.AA19027@altair.krl.caltech.edu> Subject: New addition... To: ag-directors Date: Mon, 5 Jun 1995 12:49:34 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 99 Greetings folks, Just wanted to welcome Badcoe to the ag-directors list! :-) --- Charles From charles Mon Jun 5 12:56:24 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIiG6-000fJ5C; Mon, 5 Jun 95 12:56 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA18999; Mon, 5 Jun 1995 12:56:30 -0700 Message-Id: <9506051956.AA18999@altair.krl.caltech.edu> Subject: Whoopsie... To: ag-directors Date: Mon, 5 Jun 1995 12:56:29 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 232 Hi again, In my first welcoming message to Badcoe, I seem to have accidentially placed the wrong e-mail address for him on the ag-directors list, but now I think I fixed it. So once again, Badcoe, welcome! :-) --- Charles From charles Mon Jun 5 13:14:02 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIiX4-000fJ5C; Mon, 5 Jun 95 13:13 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA19408; Mon, 5 Jun 1995 13:14:02 -0700 Message-Id: <9506052014.AA19408@altair.krl.caltech.edu> Subject: Re: What's going on currently ? To: ag-alife, ag-directors Date: Mon, 5 Jun 1995 13:14:01 -0800 (PDT) From: "Splinterwood" In-Reply-To: from "I. Badcoe" at Jun 5, 95 10:44:31 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1224 > Hi, > I've not been around much these last few weeks but I've read all > the mails and nobody seems to be saying anything about developement. Can > I have a few comments to tell me what to do next ? Well, not much has been done because many of us have been going to, or coming up to our finals week. I'm sure things will get moving again soon. As for what to do next; I'd rather not move on to the next stages of development until we get the new rush of people on. My vote is actually that we go for this week, because afterward people will be leaving for the summer. I want to get a list of people now who are going to be interested in working on it, and then we can contact them again in the fall. I think the web page is ready, and we're in a reasonable enough organization now. Christian, would you at least start composing the articles to be posted? I think we need four different ones, depending on the audience: One generic one for the AL, AI, and Games newsgroups (and c.i.www.announce) A speicific one targeting each of graphics and sound. And one reminding people on our announcements list about the project, and telling them to check out the web site. What do all of you think? --- Charles From undergrad.math.uwaterloo.ca!jmlait Mon Jun 5 13:52:06 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIj7x-000fJ5C; Mon, 5 Jun 95 13:52 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57096-3>; Mon, 5 Jun 1995 16:51:17 -0400 Date: Mon, 5 Jun 1995 16:51:08 -0400 From: Jeff Lait To: Splinterwood cc: ag-alife@krl.caltech.edu, ag-directors@krl.caltech.edu Subject: Re: What's going on currently ? In-Reply-To: <9506052014.AA19408@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 5 Jun 1995, Splinterwood wrote: > > Hi, > > I've not been around much these last few weeks but I've read all > > the mails and nobody seems to be saying anything about developement. Can > > I have a few comments to tell me what to do next ? > > Well, not much has been done because many of us have been going to, or > coming up to our finals week. I'm sure things will get moving again soon. Lucky people... I'm coming up to my midterms, ie: I still have the finals ahead of me :< > As for what to do next; I'd rather not move on to the next stages of > development until we get the new rush of people on. My vote is actually I'd rather keep going on working on getting the core engine done, ie: FE-PCX & Universe interface. I'm against stopping waiting for new people before continuing, because if we lose momentum (The little we have), we'll probably sink back down to eternal deliberation and not get anything done. > that we go for this week, because afterward people will be leaving for the > summer. I want to get a list of people now who are going to be interested > in working on it, and then we can contact them again in the fall. > I'm still here. I get about 2 wks off in August during which I will probably be out of the net, but otherwise my connection looks pretty much continous. > One generic one for the AL, AI, and Games newsgroups (and c.i.www.announce) > A speicific one targeting each of graphics and sound. Looks reasonable. - Jeff Lait (SOL) From galaxy.csc.calpoly.edu!gtaylor Mon Jun 5 17:48:45 1995 Return-Path: Received: from galaxy.csc.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sImoz-000fJ5C; Mon, 5 Jun 95 17:48 PDT Received: (from gtaylor@localhost) by galaxy.csc.calpoly.edu (8.6.11/8.6.11) id RAA03392; Mon, 5 Jun 1995 17:50:15 -0700 Date: Mon, 5 Jun 1995 17:50:11 -0700 (PDT) From: Greg Taylor To: ag-directors@krl.caltech.edu Subject: Re: What's going on currently ? In-Reply-To: <9506052014.AA19408@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > What do all of you think? > I think it's a wise idea. -=GT=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - Greg - gtaylor@galaxy.csc.calpoly.edu - 'Ere we go, 'Ere we - = Taylor - gtaylor@oboe.aix.calpoly.edu - go, 'Ere wo go, = - _________ - woodowl!taylor@lll-winken.llnl.gov - WAAAARRRRRRGGGGG!!!! - = / _ / ------------------------------------------------------------= - /___/ / - My WubbaWubbaWubba page : http://www.calpoly.edu/~gtaylor - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From mcl.ucsb.edu!uwingcat Mon Jun 5 18:33:22 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sInWB-000fJ6C; Mon, 5 Jun 95 18:33 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id SAA27158; Mon, 5 Jun 1995 18:32:45 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id SAA25814; Mon, 5 Jun 1995 18:32:44 -0700 Message-Id: <199506060132.SAA25814@mcl.mcl.ucsb.edu> Subject: Re: Debate continues... (fwd) To: ag-directors@krl.caltech.edu Date: Mon, 5 Jun 1995 18:32:44 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1805 > > > 33222222222211111111110000000000 > > > 10987654321098765432109876543210 > > > || || || | > > > || || |+-------+------+ > > > || |+---+---+ +--------- Fractional pixel position. > > > |+-+--+ +---------------------- Integral pixel position (0-511) > > > | +------------------------------ Subsector number (0-63) > > > +--------------------------------- Prevent overflow... > > > > > > With the fractional component to the pixel position the loss of a > > > bit of precision will probably be unnoticed. > > > > Waitaminute...we're doing 512 pixels per subsector? I thought that we were > > doing approx. 11 * 15 subsectors on the screen. Remember that an object > > can be as large as an entire subsector...can you really handle 512*512 sprites? > > > Ahh.. But FE does not have to worry about 512 sprites. if their > are that many subsectors on the screen we couldn't even have 32x32 > sprites! 200/15 = 40/3 = ~13 pixel sprites being the maximum with 15 > subsectors high per screen!!!! Yeah, but if you make the integral part your pixel number, then you have 1 subsector = 512*512 pixels, which would then be then maximum size of a sprite. Perhaps only the leftmost five bits of the in-subsector position should determine the sprite's position, allowing for a maximum sprite size of 32 * 32 pixels? BTW, we'll probably want less than 15 subsectors high per screen if you can. 16 wide * 12 high, perhaps? Remember, the entire game space is only 64 * 64 subsectors, and 20 wide (approx. 1/3rd) would diminish the perceived action space a bit too much, IMO. Also, do we really want boss probes that are only 13 pixels across? 1 subsector = the *MAXIMUM* diameter of a sprite; this should not be achieved by many objects! From mcl.ucsb.edu!uwingcat Mon Jun 5 18:37:08 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sInZp-000fJ7C; Mon, 5 Jun 95 18:37 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id SAA27533 for ; Mon, 5 Jun 1995 18:36:31 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id SAA26926; Mon, 5 Jun 1995 18:36:30 -0700 Message-Id: <199506060136.SAA26926@mcl.mcl.ucsb.edu> Subject: Re: POC3 (fwd) To: ag-directors@krl.caltech.edu Date: Mon, 5 Jun 1995 18:36:30 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 850 > > Sprite animation protocol. Art-sound creates the sprites, that much is obvious. > > Who is doing the animation? FE or Universe? We would assume Universe, as > > animation can be pretty platform independent. But, then we'll need to work > > out a protocol, to enable universe to simply start an animation and then to > > stop bothering about it (until it is finished). Any ideas, anyone? > > Universe, I believe. FE just needs to have the current picture > pointer correctly set. Though note that Universe can't know how the > sprites are stored in memory - current implementation of FE has sets of 4 > sprites placed side by side... Actually, the universe calls an AS routine to update the current picture. This was in universe.c 0.41 (and was one of the things I wanted a comment on), as was the entire API as I knew it at the time. From undergrad.math.uwaterloo.ca!jmlait Mon Jun 5 20:10:19 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIp1z-000fJ5C; Mon, 5 Jun 95 20:10 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57115-2>; Mon, 5 Jun 1995 23:09:32 -0400 Date: Mon, 5 Jun 1995 23:09:26 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Debate still continues... (fwd) In-Reply-To: <199506060132.SAA25814@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 5 Jun 1995, Adrian Tymes wrote: > > Ahh.. But FE does not have to worry about 512 sprites. if their > > are that many subsectors on the screen we couldn't even have 32x32 > > sprites! 200/15 = 40/3 = ~13 pixel sprites being the maximum with 15 > > subsectors high per screen!!!! > > Yeah, but if you make the integral part your pixel number, then you have > 1 subsector = 512*512 pixels, which would then be then maximum size of a > sprite. Perhaps only the leftmost five bits of the in-subsector position > should determine the sprite's position, allowing for a maximum sprite > size of 32 * 32 pixels? Hey... You're right - that does give a maximum size of 512x512 pixels in UNIVERSE COORIDINATES! However, when the FE casually scales them to whatever odd sized resolution the user is using, they will shrink. As per my example, if we go with screens 15 subsectors high, one subsector will translate to 13 pixels, regardless of whether it is 512x512 or 1024x1024 in the original format. > BTW, we'll probably want less than 15 subsectors high per screen if you > can. 16 wide * 12 high, perhaps? Remember, the entire game space is > only 64 * 64 subsectors, and 20 wide (approx. 1/3rd) would diminish > the perceived action space a bit too much, IMO. Also, do we really want > boss probes that are only 13 pixels across? 1 subsector = the *MAXIMUM* > diameter of a sprite; this should not be achieved by many objects! Har! Funny you should say that. I never wanted small subsectors. Check POC I - one subsector ~= one screen. Remember my incredulity when I was informed the universe was planning 11x8 or whatever? Go ahead, make it whatever, the 15 was just an example to show how the number of pixels per subsector on the Unvierse end has no direct correlation to the number on hte FE side without taking into accound resolutio, subsecotrs per screen, etc. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Mon Jun 5 20:13:11 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIp4m-000fJ6C; Mon, 5 Jun 95 20:13 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57109-3>; Mon, 5 Jun 1995 23:12:26 -0400 Date: Mon, 5 Jun 1995 23:12:12 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu Subject: Re: POC4 (fwd) In-Reply-To: <199506060136.SAA26926@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 5 Jun 1995, Adrian Tymes wrote: > Actually, the universe calls an AS routine to update the current picture. > This was in universe.c 0.41 (and was one of the things I wanted a comment > on), as was the entire API as I knew it at the time. > Speaking of Universe.c 0.41, I have it, but am unable to use it until a universe.h appears or similar - I considered hacking together a list of exports, but I'd rather use the Universe API directly from the universe group (That way, if I have a problem with it, I know I have a problem with the actual implementation, not my interpretation of it.) I'll comment on Universe.c when I can actually link it into POC4. - Jeff Lait (SOL) From dl.ac.uk!mbbad Tue Jun 6 04:09:23 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIwVT-000fJ5C; Tue, 6 Jun 95 04:09 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id MAA20710 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Tue, 6 Jun 1995 12:08:28 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA02321; Tue, 6 Jun 95 12:08:21 +0100 Date: Tue, 6 Jun 1995 12:08:20 +0100 (BST) From: "I. Badcoe" Subject: Re: Debate still continues... (fwd) Cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 5 Jun 1995, Jeff Lait wrote: Hi Guys! Just thought I'd but in to the middle of this discussion to let you know I am here. > Har! Funny you should say that. I never wanted small > subsectors. Check POC I - one subsector ~= one screen. Remember my > incredulity when I was informed the universe was planning 11x8 or > whatever? Go ahead, make it whatever, the 15 was just an example to show > how the number of pixels per subsector on the Unvierse end has no direct > correlation to the number on hte FE side without taking into accound > resolutio, subsecotrs per screen, etc. The original idea of a sub-sector (and I *think* it is still the idea) was so that the sprites in each ssector could be kept in a linked list to facilitate collision detection. In this case the maximum size of a sprite is *half* the size of a ssector (this means that anything in *could* collide with must have its origin in 1 of 4 ssectors, in 1-dimension: (ssector_length = 16; sprite_max = 8) (the dot is the first point in a ssector) ssector 1 ssector 2 ssector 3 __._______________._______________._______________.__ ----1--- ++++++++ ++++++++ ----2--- ******** ******** 1 is the left-most a sprite can be in ssector 2 and *could* collide with sprites in ssectors 1 or 2 2 is the right-most a sprite can be in ssector 2 and *could* collide with sprites in ssectors 2 or 3 **BUT** This was all addapted from some of my existing stuff which was heavily predicated on having "pixel-perfect" collision dectector *inside* the bbox-cd. Since this relies on bit-shifting an int (or long int or long-long int) to represent each row of the image this limits our maximum sprite size to be the same as the number of bits in our maximum data-type. e.g 32 (or perhaps 64, what can your compiler handle ?) Given a virtual coordinate system this may not make as much sense (less precision between a collision detected by coordinate manipulations in the universe code and that apparent to the user on the display) so we might want to nest a simple circle (or octagon is cheap) overlap routine inside the bbix-cd. In this case we can make the sprite max (and ssector size) as large as we like. Badders From undergrad.math.uwaterloo.ca!jmlait Tue Jun 6 06:58:18 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIz94-000fJ5C; Tue, 6 Jun 95 06:58 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57108-1>; Tue, 6 Jun 1995 09:57:26 -0400 Date: Tue, 6 Jun 1995 09:57:11 -0400 From: Jeff Lait To: "I. Badcoe" cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Debate still continues... (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, I. Badcoe wrote: > This was all addapted from some of my existing stuff which was > heavily predicated on having "pixel-perfect" collision dectector *inside* > the bbox-cd. Since this relies on bit-shifting an int (or long int or > long-long int) to represent each row of the image this limits our maximum > sprite size to be the same as the number of bits in our maximum > data-type. e.g 32 (or perhaps 64, what can your compiler handle ?) > But doesn't that assume upon how FE implements the pixel perfect collision detection? And also upon what size the sprites are in FE pixels? Neither of which the Universe knows. You must have missed an earlier discussion where I mentioned that currently FE-PCX will be detecting according to a circular shield, not the actual sprite (The sprite rotates 256 degrees, making it difficult to do a standard pixel by pixel test) Remember, maximum sprites size according to Universe is NOT the same as that in FE, as pixels are different sizes. > Given a virtual coordinate system this may not make as much sense > (less precision between a collision detected by coordinate manipulations > in the universe code and that apparent to the user on the display) so we > might want to nest a simple circle (or octagon is cheap) overlap routine > inside the bbix-cd. In this case we can make the sprite max (and ssector > size) as large as we like. > This is exactly the plan. We're also planning on making it obvious to the user that this is the case: ie: the shields flash when hit. - Jeff Lait (SOL) From post.demon.co.uk!darkin.demon.co.uk!Christian Tue Jun 6 07:17:37 1995 Return-Path: <@post.demon.co.uk:Christian@darkin.demon.co.uk> Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIzQb-000fJ5C; Tue, 6 Jun 95 07:16 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id aa10015; 6 Jun 95 15:15 +0100 Received: from darkin.demon.co.uk by post.demon.co.uk id aa17907; 6 Jun 95 15:15 +0100 Date: Tue, 6 Jun 1995 07:53:57 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <214@darkin.demon.co.uk> To: ag-directors@krl.caltech.edu, ag-alife@krl.caltech.edu, charles@krl.caltech.edu Subject: Re: Re: What's going on currently ? X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 27 In your message dated Monday 5, June 1995 you wrote : > I think the web page is ready, and we're in a reasonable enough organization > now. Christian, would you at least start composing the articles to be > posted? I think we need four different ones, depending on the audience: > > One generic one for the AL, AI, and Games newsgroups (and c.i.www.announce) > A speicific one targeting each of graphics and sound. > And one reminding people on our announcements list about the project, and > telling them to check out the web site. > > What do all of you think? Yes. Will do. > > --- Charles > > > -- Christian Darkin From phil.ruu.nl!faassen Tue Jun 6 07:51:20 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sIzyA-000fJ6C; Tue, 6 Jun 95 07:51 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id QAA08513; Tue, 6 Jun 1995 16:50:23 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id QAA06832; Tue, 6 Jun 1995 16:50:19 +0200 From: Martijn Faassen Message-Id: <199506061450.QAA06832@laurel.stud.phil.ruu.nl> Subject: Subsector Size To: ag-directors@alnilam.krl.caltech.edu (AG Directors), ag-fe@krl.caltech.edu (fe), ag-universe@alnilam.krl.caltech.edu (ag universe) Date: Tue, 6 Jun 1995 16:50:18 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1011 Hello everybody, Am I right that, after reading the discussion on subsectors, their size can be any size? I'd say make them not too small. 1 subsector per screen or less would be okay, I suppose. But, some comments: Front end remaps universe coordinates. It also manages sprite sizes in pixels, about which Universe doesn't need to know. But, doesn't Universe need to know something about sprite sizes (in universe coordinates)? Because the collision detection needs to check the bounding box; and if we go for a further test involving circular shields, I don't see why Universe can't manage that part either. So, this needs to be worked out between FE and Universe. (so that all FEs will have the same relationship to 'physical pixel' sizes on the screen, and Universe coordinate sizes.) Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From phil.ruu.nl!faassen Tue Jun 6 07:58:51 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ05C-000fJ8C; Tue, 6 Jun 95 07:58 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id QAA08698; Tue, 6 Jun 1995 16:57:39 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id QAA07042; Tue, 6 Jun 1995 16:57:36 +0200 From: Martijn Faassen Message-Id: <199506061457.QAA07042@laurel.stud.phil.ruu.nl> Subject: What's going on currently for me To: ag-alife@alnilam.krl.caltech.edu (ag alife), ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 6 Jun 1995 16:57:35 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1213 The reason I haven't been contributing much recently is because I'm taking courses for a period of 6 weeks. (am now in the third week). Early july, I'll have finals. Then, until the near end of july, I'll probably be able to contribute more again. Then, until near the end of august I'll be on vacation, and will be unable to reach my mailbox. I'll be across the pond, so perhaps I'll actually be able to meet some of you people. :) Anyway, my apologies especially to Badcoe for still not having checked his code (though I'm using DJGPP, I don't have Watcom..). This stuff is slowly fermenting in my head, though, and experience suggests something will roll out of that in a while. Talking about DJGPP. I know it has a horrid assembler format, and probably isn't compatible with TASM files, but if there would be some way to convert the front end stuff (when it's workable) to DJGPP (for dos), I'd appreciate that. (being able to test stuff directly on your own computer is very helpful :) Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From dl.ac.uk!mbbad Tue Jun 6 08:12:27 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ0IK-000fJ6C; Tue, 6 Jun 95 08:11 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id QAA00842 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Tue, 6 Jun 1995 16:11:07 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA06362; Tue, 6 Jun 95 16:11:05 +0100 Date: Tue, 6 Jun 1995 16:11:04 +0100 (BST) From: "I. Badcoe" Subject: Re: Debate still continues... (fwd) Cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Jeff Lait wrote: > On Tue, 6 Jun 1995, I. Badcoe wrote: > > This was all addapted from some of my existing stuff which was > > heavily predicated on having "pixel-perfect" collision dectector *inside* > > the bbox-cd. Since this relies on bit-shifting an int (or long int or > > long-long int) to represent each row of the image this limits our maximum > > sprite size to be the same as the number of bits in our maximum > > data-type. e.g 32 (or perhaps 64, what can your compiler handle ?) > But doesn't that assume upon how FE implements the pixel perfect > collision detection? And also upon what size the sprites are in FE > pixels? Neither of which the Universe knows. You must have missed an > earlier discussion where I mentioned that currently FE-PCX will be > detecting according to a circular shield, not the actual sprite (The > sprite rotates 256 degrees, making it difficult to do a standard pixel > by pixel test) > Remember, maximum sprites size according to Universe is NOT the > same as that in FE, as pixels are different sizes. That's silly (isn't it ?) either FE is doing the collision detection *or* universe is doing it, in either case, surely the other doesn't need to know anything about sprites. In the universe code that we have at present, universe does the CD. This actually raises a general point, which is that the directors group seem to have had quite a few discussion in which decisions were made but which were not very-well reported to the "underlings", or rather, that got reported to some of the sub-groups but not to others. To take a case in point, what's POC3 ? > > Given a virtual coordinate system this may not make as much sense > > (less precision between a collision detected by coordinate manipulations > > in the universe code and that apparent to the user on the display) so we > > might want to nest a simple circle (or octagon is cheap) overlap routine > > inside the bbix-cd. In this case we can make the sprite max (and ssector > > size) as large as we like. > This is exactly the plan. We're also planning on making it > obvious to the user that this is the case: ie: the shields flash when hit. A good and sensible plan. Do we also have a plan for the update order for the various parts, I'd prefer: Move-all Collide-all Explode-all ALife-all To: Foreach { move collide explode ALife } which is what (I think) we have in universe at present. Badders From undergrad.math.uwaterloo.ca!jmlait Tue Jun 6 08:31:38 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ0bP-000fJ9C; Tue, 6 Jun 95 08:31 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57122-2>; Tue, 6 Jun 1995 11:30:51 -0400 Date: Tue, 6 Jun 1995 11:30:46 -0400 From: Jeff Lait To: Martijn Faassen cc: AG Directors , fe , ag universe Subject: Re: Subsector Size In-Reply-To: <199506061450.QAA06832@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Martijn Faassen wrote: > > Hello everybody, > > Am I right that, after reading the discussion on subsectors, their size > can be any size? I'd say make them not too small. 1 subsector per screen > or less would be okay, I suppose. > Yo... Any size above a certain minimum. As a result, I'm for making 'em large. > But, some comments: > > Front end remaps universe coordinates. It also manages sprite sizes in > pixels, about which Universe doesn't need to know. But, doesn't Universe > need to know something about sprite sizes (in universe coordinates)? Because Yep. > the collision detection needs to check the bounding box; and if we go > for a further test involving circular shields, I don't see why Universe > can't manage that part either. So, this needs to be worked out between FE It could, but someone mentioned they'd like ultra fast tests via ASM or something. > and Universe. (so that all FEs will have the same relationship to 'physical > pixel' sizes on the screen, and Universe coordinate sizes.) > They shouldn't have the same physical pixel/univerrse coordinate ratio!!!! Instead, they should have the same number of universe coordinates per physical viewing area. The pixel mapping depends upon resolution. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Tue Jun 6 08:37:08 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ0gj-000fJ8C; Tue, 6 Jun 95 08:37 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57124-2>; Tue, 6 Jun 1995 11:36:21 -0400 Date: Tue, 6 Jun 1995 11:36:04 -0400 From: Jeff Lait To: "I. Badcoe" cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Debate still continues... (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > But doesn't that assume upon how FE implements the pixel perfect > > collision detection? And also upon what size the sprites are in FE > > pixels? Neither of which the Universe knows. You must have missed an > > earlier discussion where I mentioned that currently FE-PCX will be > > detecting according to a circular shield, not the actual sprite (The > > sprite rotates 256 degrees, making it difficult to do a standard pixel > > by pixel test) > > Remember, maximum sprites size according to Universe is NOT the > > same as that in FE, as pixels are different sizes. > > That's silly (isn't it ?) either FE is doing the collision detection *or* > universe is doing it, in either case, surely the other doesn't need to > know anything about sprites. In the universe code that we have at > present, universe does the CD. > ACtually, currently both our doing it. Why? I guess it is for speed as pixel level detection would be better to throw into the FE. Of course, circular detection could probably be done at the universe level with no probs, but I was told when I brought up circular shields that the detection should be performed at FE level. > This actually raises a general point, which is that the directors group > seem to have had quite a few discussion in which decisions were made but > which were not very-well reported to the "underlings", or rather, that got > reported to some of the sub-groups but not to others. To take a case in > point, what's POC3 ? > Don't fear it is an elitist method that resulted in this. Many decisions have been made at the Universe level which affect FE that I only learn of after a great deal of misunderstanding :> In a project like this, poor communication is something we have to live with. Still, I am thankful that we have as good a communication system that we do, thanks to the mailing lists. As for POC3, check out the FTP site, it should be there now. It is a PC based implementation of the FE engine, which doesn't conform to the universe API. IT will do that once I get the universe API :> > > This is exactly the plan. We're also planning on making it > > obvious to the user that this is the case: ie: the shields flash when hit. > > A good and sensible plan. > > Do we also have a plan for the update order for the various parts, I'd > prefer: > I'd have to check Universe.c to confirm what it is. It is really purely a universe concern. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Tue Jun 6 09:31:15 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ1X4-000fJ5C; Tue, 6 Jun 95 09:31 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57125-2>; Tue, 6 Jun 1995 12:30:21 -0400 Date: Tue, 6 Jun 1995 12:30:16 -0400 From: Jeff Lait To: Martijn Faassen cc: ag alife , AG Directors Subject: Re: What's going on currently for me In-Reply-To: <199506061457.QAA07042@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Martijn Faassen wrote: > Talking about DJGPP. I know it has a horrid assembler format, and probably > isn't compatible with TASM files, but if there would be some way to > convert the front end stuff (when it's workable) to DJGPP (for dos), I'd > appreciate that. (being able to test stuff directly on your own computer > is very helpful :) Isn't that the format where every operand is prefixed by shift-numeral, and operands are written backwards :> As for conversion, might be something automated out there - FEASM is pretty much MASM compliant (Though don't quote me on that :>) right now. As for testing, why don't we just distribute the obj files with it (As I did in POC3) so those lacking the required assemblers can still use it. - Jeff Lait (SOL) From mcl.ucsb.edu!uwingcat Tue Jun 6 10:08:51 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ27T-000fJ6C; Tue, 6 Jun 95 10:08 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id KAA06111; Tue, 6 Jun 1995 10:08:11 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id KAA05291; Tue, 6 Jun 1995 10:08:11 -0700 Message-Id: <199506061708.KAA05291@mcl.mcl.ucsb.edu> Subject: Re: Debate still continues... (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 6 Jun 1995 10:08:11 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2240 > > > But doesn't that assume upon how FE implements the pixel perfect > > > collision detection? And also upon what size the sprites are in FE > > > pixels? Neither of which the Universe knows. You must have missed an > > > earlier discussion where I mentioned that currently FE-PCX will be > > > detecting according to a circular shield, not the actual sprite (The > > > sprite rotates 256 degrees, making it difficult to do a standard pixel > > > by pixel test) > > > Remember, maximum sprites size according to Universe is NOT the > > > same as that in FE, as pixels are different sizes. > > > > That's silly (isn't it ?) either FE is doing the collision detection *or* > > universe is doing it, in either case, surely the other doesn't need to > > know anything about sprites. In the universe code that we have at > > present, universe does the CD. > > > ACtually, currently both our doing it. Why? I guess it is for > speed as pixel level detection would be better to throw into the FE. Of > course, circular detection could probably be done at the universe level > with no probs, but I was told when I brought up circular shields that the > detection should be performed at FE level. The proposal used in universe.c 0.41 was that, after performing a bounding-box detection, universe.c would call FE to detect collisions using either a bitmap-bitmap detection or a circle-circle detection, *DEPENDING ON THE FE IMPLEMENTATION FOR THAT PLATFORM*. This, obviously, can not be relegated to universe.c . Should we change it so that all checks are circle-circle, regardless of platform? > As for POC3, check out the FTP site, it should be there now. It > is a PC based implementation of the FE engine, which doesn't conform to > the universe API. IT will do that once I get the universe API :> Which I gave you in the form of universe.c 0.41 . > > Do we also have a plan for the update order for the various parts, I'd > > prefer: > > > I'd have to check Universe.c to confirm what it is. It is really > purely a universe concern. True...BTW, what's the current membership of ag-universe? To my knowledge, everyone on that list who has programmed any part of universe.c is also on this list. From mcl.ucsb.edu!uwingcat Tue Jun 6 10:13:41 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ2C5-000fJ5C; Tue, 6 Jun 95 10:13 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id KAA06535; Tue, 6 Jun 1995 10:12:57 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id KAA06348; Tue, 6 Jun 1995 10:12:57 -0700 Message-Id: <199506061712.KAA06348@mcl.mcl.ucsb.edu> Subject: Re: Subsector Size (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 6 Jun 1995 10:12:57 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 696 > > Am I right that, after reading the discussion on subsectors, their size > > can be any size? I'd say make them not too small. 1 subsector per screen > > or less would be okay, I suppose. > > > Yo... Any size above a certain minimum. As a result, I'm for > making 'em large. Note that there are two limits on object size: FE can't handle greater than a certain number of pixels per object, and UN can't handle objects more than 1/2 a subsector by 1/2 a subsector. We're trying to make those limits as equal as possible so we don't wind up wasting potential. > It could, but someone mentioned they'd like ultra fast tests via > ASM or something. Said tests may soon be eliminated. From undergrad.math.uwaterloo.ca!jmlait Tue Jun 6 10:44:48 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ2gD-000fJ5C; Tue, 6 Jun 95 10:44 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57122-2>; Tue, 6 Jun 1995 13:43:42 -0400 Date: Tue, 6 Jun 1995 13:43:39 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Debate still continues... (fwd) In-Reply-To: <199506061708.KAA05291@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Adrian Tymes wrote: > > As for POC3, check out the FTP site, it should be there now. It > > is a PC based implementation of the FE engine, which doesn't conform to > > the universe API. IT will do that once I get the universe API :> > > Which I gave you in the form of universe.c 0.41 . > Actually, not quite... As I've been saying for a while, universe.c is useless without the associated .H file so I know what the hell is exported (Ie: types etc.) An uptodate H file is what I'm waiting for, as to rip one out myself would probably result in me changing what the universe expects the API to be. > True...BTW, what's the current membership of ag-universe? To my knowledge, > everyone on that list who has programmed any part of universe.c is also on > this list. > I'm not on the list. Mind you, judging by the traffic in UNIVERSE (From the archives), I don't think I want to be :> ag-fe should be sufficient as this allows us to discuss the api away from directors. - Jeff Lait (SOL) From mcl.ucsb.edu!uwingcat Tue Jun 6 10:49:57 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ2lG-000fJ6C; Tue, 6 Jun 95 10:49 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id KAA09666; Tue, 6 Jun 1995 10:49:18 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id KAA16817; Tue, 6 Jun 1995 10:49:18 -0700 Message-Id: <199506061749.KAA16817@mcl.mcl.ucsb.edu> Subject: Re: Debate still continues... (fwd) To: ag-directors@krl.caltech.edu Date: Tue, 6 Jun 1995 10:49:18 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 507 > Actually, not quite... As I've been saying for a while, > universe.c is useless without the associated .H file so I know what the > hell is exported (Ie: types etc.) An uptodate H file is what I'm waiting > for, as to rip one out myself would probably result in me changing what > the universe expects the API to be. Ok, I'll upload a .h file when I upload universe.c 0.42 > ag-fe should > be sufficient as this allows us to discuss the api away from directors. If ag-universe is added to it... From undergrad.math.uwaterloo.ca!jmlait Tue Jun 6 10:50:15 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ2lY-000fJ7C; Tue, 6 Jun 95 10:50 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57125-3>; Tue, 6 Jun 1995 13:49:27 -0400 Date: Tue, 6 Jun 1995 13:49:24 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Subsector Size (fwd) In-Reply-To: <199506061712.KAA06348@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Adrian Tymes wrote: > > > Am I right that, after reading the discussion on subsectors, their size > > > can be any size? I'd say make them not too small. 1 subsector per screen > > > or less would be okay, I suppose. > > > > > Yo... Any size above a certain minimum. As a result, I'm for > > making 'em large. > > Note that there are two limits on object size: FE can't handle greater than > a certain number of pixels per object, and UN can't handle objects more > than 1/2 a subsector by 1/2 a subsector. We're trying to make those > limits as equal as possible so we don't wind up wasting potential. > I really don't see why making the limits equal saves any potential. The limit of the subsector should be determined by a couple of tradeoffs: 1) Maximum size. But as maximum size can be LESS than the subsector size with no probs, this is irrelevant with subsectors above a certain size. 2) The smaller the subsectors, the fewer the objects that need to be tested for collisions (As collisions can onlyt occur between adjacent subsectors, no?). Ie: faster code. 3) The smaller the subsectors, the more UN_SHIFTS req'd to move objects between subsectors: Ie: slower code. 2 & 3 need to be ballanced while assuring 1 remains true. FEs max has nothing to do with this, as we're going to have a maximum object size independent of subsectors anyways, right?? > > It could, but someone mentioned they'd like ultra fast tests via > > ASM or something. > > Said tests may soon be eliminated. > As a note: If thjis is removed from FE-PCX Universe will have to handle the appropriate flags relating to handling the shield glow... - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Tue Jun 6 12:16:40 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ47A-000fJ5C; Tue, 6 Jun 95 12:16 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57125-1>; Tue, 6 Jun 1995 15:15:48 -0400 Date: Tue, 6 Jun 1995 15:15:42 -0400 From: Jeff Lait To: Adrian Tymes cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu Subject: Re: Debate still continues... (fwd) In-Reply-To: <199506061749.KAA16817@mcl.mcl.ucsb.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Adrian Tymes wrote: > Ok, I'll upload a .h file when I upload universe.c 0.42 > Any idea when that will be? > > ag-fe should > > be sufficient as this allows us to discuss the api away from directors. > > If ag-universe is added to it... > Hey Charles: has this been added yet? If not, could you please do it? I'd like to get this off the directors news feed. - Jeff Lait (SOL) From charles Tue Jun 6 13:08:48 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ4vc-000fJ5C; Tue, 6 Jun 95 13:08 PDT Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA17927; Tue, 6 Jun 1995 13:08:35 -0700 Message-Id: <9506062008.AA17927@rigel.krl.caltech.edu> Subject: Re: Debate still continues... (fwd) To: uwingcat@mcl.ucsb.edu (Adrian Tymes) Date: Tue, 6 Jun 1995 13:08:35 -0800 (PDT) From: "Splinterwood" Cc: ag-directors, ag-fe In-Reply-To: <199506061749.KAA16817@mcl.mcl.ucsb.edu> from "Adrian Tymes" at Jun 6, 95 10:49:18 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 407 > Ok, I'll upload a .h file when I upload universe.c 0.42 Okay - tell me when you do so I know to move it into the programs directory. > > ag-fe should > > be sufficient as this allows us to discuss the api away from directors. > > If ag-universe is added to it... Should I do this? Or should I just move specific people from ag-universe also onto the ag-fe list. Up to you folks. --- Charles From charles Tue Jun 6 14:51:21 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ6Wt-000fJ5C; Tue, 6 Jun 95 14:51 PDT Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA20823; Tue, 6 Jun 1995 14:51:10 -0700 Message-Id: <9506062151.AA20823@rigel.krl.caltech.edu> Subject: Re: Debate still continues... To: jmlait@undergrad.math.uwaterloo.ca (Jeff Lait) Date: Tue, 6 Jun 1995 14:51:10 -0800 (PDT) From: "Splinterwood" Cc: ag-directors In-Reply-To: from "Jeff Lait" at Jun 6, 95 05:43:45 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 742 > Well... I guess all it does is remove a line from the header > then, eh? :> Though I have been getting a couple of duplicate messages > in the past, which hopefully this will alleviate ??? > - Jeff Lait (SOL) You've really been getting duplicate messages?? Hmmm... I had hoped that I had fixed that; its supposed to evaulate the lists mailed to and remove all repition of addresses. I haven't gotten any duplicates since I set that up, but I guess it may only work for on site. I'll look into it some more. Perhaps I should manually expand the ag-fe group from all the groups it contains and forcibly take out any repeated names of people on multiple lists. Is everyone else getting duplicate messages as well? --- Charles From charles Tue Jun 6 15:07:46 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJ6mm-000fJ6C; Tue, 6 Jun 95 15:07 PDT Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA21022; Tue, 6 Jun 1995 15:07:35 -0700 Message-Id: <9506062207.AA21022@rigel.krl.caltech.edu> Subject: Duplicate messages... To: ag-directors Date: Tue, 6 Jun 1995 15:07:35 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 462 Greetings, Martaijn just pointed out what's going on; If someone replys to the person and to the list, then that person will get two copies. In my case the second copy is still removed since I'm on the local machine, but in the case of eveyone else, the second copy goes straight to them, so my machine never knows it was sent, and sends you a copy via the list as well. Make sense? --- Charles PS: If this is not what's happening, please let me know. From undergrad.math.uwaterloo.ca!jmlait Tue Jun 6 21:35:19 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJCpn-000fJ5C; Tue, 6 Jun 95 21:35 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57129-1>; Wed, 7 Jun 1995 00:34:30 -0400 Date: Wed, 7 Jun 1995 00:34:25 -0400 From: Jeff Lait cc: ag-directors@krl.caltech.edu To: ag-directors@krl.caltech.edu Subject: Re: Duplicate messages... In-Reply-To: <9506062207.AA21022@rigel.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Splinterwood wrote: > Greetings, > > Martaijn just pointed out what's going on; If someone replys to the > person and to the list, then that person will get two copies. In my case > the second copy is still removed since I'm on the local machine, but in the > case of eveyone else, the second copy goes straight to them, so my machine > never knows it was sent, and sends you a copy via the list as well. Make > sense? Yep.,, That would also explain why I get duplicates incosistantly. I guess we should get in the habit of removing the direct reply from the sending list... - Jeff Lait (SOL) From dl.ac.uk!mbbad Wed Jun 7 02:26:08 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJHN2-000fJ5C; Wed, 7 Jun 95 02:25 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id KAA25740 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Wed, 7 Jun 1995 10:24:53 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-alife@alnilam.krl.caltech.edu id AA21508; Wed, 7 Jun 95 10:24:52 +0100 Date: Wed, 7 Jun 1995 10:24:51 +0100 (BST) From: "I. Badcoe" Subject: Re: What's going on currently for me Cc: ag alife , AG Directors In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Jeff Lait wrote: > On Tue, 6 Jun 1995, Martijn Faassen wrote: > > Talking about DJGPP. I know it has a horrid assembler format, and probably > > isn't compatible with TASM files, but if there would be some way to > > convert the front end stuff (when it's workable) to DJGPP (for dos), I'd > > appreciate that. (being able to test stuff directly on your own computer > > is very helpful :) > Isn't that the format where every operand is prefixed by > shift-numeral, and operands are written backwards :> > As for conversion, might be something automated out there - FEASM > is pretty much MASM compliant (Though don't quote me on that :>) right > now. As for testing, why don't we just distribute the obj files with it > (As I did in POC3) so those lacking the required assemblers can still use > it. A lot of people have been screeming for an Intel<->AT&T ASM converter for a long time. I havn't seen one yet. Personally I find it easy enough to do in my head but them I only ever have 10's - 100's of lines of ASM to considder :-). Badders From dl.ac.uk!mbbad Wed Jun 7 02:33:46 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJHUY-000fJ6C; Wed, 7 Jun 95 02:33 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id KAA26100 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Wed, 7 Jun 1995 10:32:23 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA23217; Wed, 7 Jun 95 10:32:17 +0100 Date: Wed, 7 Jun 1995 10:32:15 +0100 (BST) From: "I. Badcoe" Subject: Re: Debate still continues... (fwd) Cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu In-Reply-To: <199506061708.KAA05291@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Adrian Tymes wrote: > > > That's silly (isn't it ?) either FE is doing the collision detection *or* > > > universe is doing it, in either case, surely the other doesn't need to > > > know anything about sprites. In the universe code that we have at > > > present, universe does the CD. > > ACtually, currently both our doing it. Why? I guess it is for > > speed as pixel level detection would be better to throw into the FE. Of > > course, circular detection could probably be done at the universe level > > with no probs, but I was told when I brought up circular shields that the > > detection should be performed at FE level. > The proposal used in universe.c 0.41 was that, after performing a > bounding-box detection, universe.c would call FE to detect collisions > using either a bitmap-bitmap detection or a circle-circle detection, > *DEPENDING ON THE FE IMPLEMENTATION FOR THAT PLATFORM*. This, obviously, > can not be relegated to universe.c. Bitwise would have to be in FE. Circular would be better in universe. > Should we change it so that all > checks are circle-circle, regardless of platform? I think that would be the fastest form of progress for the moment. Also, nice though bitwise CD is, it's really only relevant to a system where "the pixels *are* the universe", as soon as you have the game sizes abstracted from the pixels then there's no real justification for bitwise-CD. There are some compromises that we could get back to if necessary at a latter date. > > As for POC3, check out the FTP site, it should be there now. It > > is a PC based implementation of the FE engine, which doesn't conform to > > the universe API. IT will do that once I get the universe API :> Remind me of the FTP address (what! you mean you've NEVER EVEN LOOKED !!!). > > > Do we also have a plan for the update order for the various parts, I'd > > > prefer: > > I'd have to check Universe.c to confirm what it is. It is really > > purely a universe concern. I think it's on the universe/FE border 'cos, for example, it might be advantagous to do it one way of the other depending on the screen-refresh strategy. > True...BTW, what's the current membership of ag-universe? To my knowledge, > everyone on that list who has programmed any part of universe.c is also on > this list. This == directors ? I think there's a strong alife == universe corellation as well. Badders From dl.ac.uk!mbbad Wed Jun 7 02:46:32 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJHge-000fJ5C; Wed, 7 Jun 95 02:46 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id KAA26961 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Wed, 7 Jun 1995 10:45:22 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA26952; Wed, 7 Jun 95 10:45:21 +0100 Date: Wed, 7 Jun 1995 10:45:19 +0100 (BST) From: "I. Badcoe" Subject: Re: Subsector Size (fwd) Cc: ag-directors@krl.caltech.edu, ag-fe@krl.caltech.edu In-Reply-To: <199506061712.KAA06348@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jun 1995, Adrian Tymes wrote: > Note that there are two limits on object size: FE can't handle greater than > a certain number of pixels per object, and UN can't handle objects more > than 1/2 a subsector by 1/2 a subsector. We could have 'special cases' for a small number of objects larger than 1/2 a subsector, for example for an object the same size as a ssector: ssect 1 ssect 2 ssect 3 ssect 4 ssect 5 __._______._______._______._______._______.__ ---1---- ++++++++ ++++++++ ---2---- ******** ******** ssector size = 8, 1 is the left-most position for a sprite in ssect 2, 2 is the right-most in this case we need to check 3 (9 in 2D) ssectors to get any possible collision with an sprite in ssect 2 The problem is that the number of ssects that need to be checked is a property of *both* sprite sizes so it would be awkward to have a large range of sizes around. However, if we drop bitwise-CD we no longer have an upper limit on sprite-size from that so we may as well increase the ssect size and keep the bbox-CD as it is. > We're trying to make those > limits as equal as possible so we don't wind up wasting potential. > > It could, but someone mentioned they'd like ultra fast tests via > > ASM or something. > Said tests may soon be eliminated. Which ones ? Badders From undergrad.math.uwaterloo.ca!jmlait Wed Jun 7 06:24:25 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJL5o-000fJ6C; Wed, 7 Jun 95 06:24 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56884-2>; Wed, 7 Jun 1995 09:23:21 -0400 Date: Wed, 7 Jun 1995 09:23:10 -0400 From: Jeff Lait To: "I. Badcoe" cc: ag alife , AG Directors Subject: Re: What's going on currently for me In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > A lot of people have been screeming for an Intel<->AT&T ASM converter for > a long time. I havn't seen one yet. Personally I find it easy enough to > do in my head but them I only ever have 10's - 100's of lines of ASM to > considder :-). > Hey, if you feel up to it, feel free to convert FEASM.ASM to AT&T! As I understand, the hardest thing about the conversion is the vast amount of typing involved - not to mention that to keep both versions up to date would be painful... Really, we need something automated. (How difficult would you say it would be to automate it?? Judging from the fact no such utility appears to be around, there must be some trick, no?) - Jeff Lait (SOL) From charles Wed Jun 7 08:39:20 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJNCQ-000fJ5C; Wed, 7 Jun 95 08:39 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA00194; Wed, 7 Jun 1995 08:39:20 -0700 Message-Id: <9506071539.AA00194@altair.krl.caltech.edu> Subject: mailing lists... To: ag-directors Date: Wed, 7 Jun 1995 08:39:19 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 315 Greetings, The listing of who is on every mailing list at the archive (in the pub/alife-game/admin/mailing-lists directory) is now being updated every day, so if anyone needs an exact list of people on a mailing list, you can get it there. I'll try to link this into the web page soon as well. --- Charles From dl.ac.uk!mbbad Wed Jun 7 09:43:58 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJOBT-000fJ5C; Wed, 7 Jun 95 09:42 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id RAA19027 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Wed, 7 Jun 1995 17:41:33 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-alife@alnilam.krl.caltech.edu id AA01988; Wed, 7 Jun 95 17:41:29 +0100 Date: Wed, 7 Jun 1995 17:41:28 +0100 (BST) From: "I. Badcoe" Subject: Re: What's going on currently for me Cc: ag alife , AG Directors In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 7 Jun 1995, Jeff Lait wrote: > > A lot of people have been screeming for an Intel<->AT&T ASM converter for > > a long time. I havn't seen one yet. Personally I find it easy enough to > > do in my head but them I only ever have 10's - 100's of lines of ASM to > > considder :-). > Hey, if you feel up to it, feel free to convert FEASM.ASM to > AT&T! As I understand, the hardest thing about the conversion is the > vast amount of typing involved - not to mention that to keep both > versions up to date would be painful... Really, we need something > automated. (How difficult would you say it would be to automate it?? > Judging from the fact no such utility appears to be around, there must be > some trick, no?) Well, coincidences crop up when you don't expect them, somebody just posted this sed script on comp.compilers.djgpp They hadn't tested it and neither have I but I will (sometime). ************************************************************************BEGIN #\ # @(#)as386.sed 1.1 - 86/11/17\ #\ # This is a sed script which converts Intel 386 assembly code to Unix\ # 386 assembly code\ #\ # This script does not attempt to convert 100% of the ASM386 source code,\ # it cannot handle the following constructs:\ #\ # - strange segmentation schemes\ # - data declarations beyond the simple db/dw/dd with simple init list\ # - ascii strings\ # - structure template addressing (i.e., [ebp].foo)\ # - complex expressions (parenthesis and operators other than +-*/)\ # - immediate operands that are not simple constants\ # - immediate operands with automatically typed memory operands\ # - source files in upper case\ # - source files with continued lines\ #\ # A typical way to use this sed script is:\ # tr "[A-Z]" "[a-z]" outfile\ #\ #\ # Meaning of labels:\ #\ # cmpress preserve comments, insert tabs, change '?' to '_'\ # control convert '$' control lines\ # segment convert segmentation directives\ # equate convert 'equ' directives\ # data convert db/dw/dd data declarations\ # modifer delete address/type modifiers\ # registr convert register names\ # bincons convert binary/octal/hex conatants\ # address regularize addess expressions, delete unneeded tabs\ # normliz normalize instruction formats (name-tab-opcode-tab-operands)\ # operand swap operands, convert scale/index/base address format\ # opcode append b/w to opcode for byte/word register operands\ # comment restore preserved comments\ :cmpress h s/;.*$// s/[ ]*$/ / s/[ ][ ]*/ /g s/\([][)(.,:*/+-]\)/ \1 /g s/ ? / 0 /g s/?/_/g s/[ ][ ]*/ /g :control s/^\$[ ]*include ( \([^ .)]*\)[^)]*)/#include "\1.h"/ s/^\$[ ]*eject /; / /^\$/ s/^/;/ :segment / segment e[or] / s/^/ .text ;/ / segment ro / s/^/ .text ;/ / segment rw / s/^/ .data ;/ / ends / s/^/;/ / stackseg / s/^/;/ s/^[ ]*name \([^ ]*\)/ .file "\1"/ /^[ ]*end / s/^/;/ /^[ ]*assume / s/^/;/ /^[ ]*extrn / s/^/;/ /^[ ]*public [^ ,]* , / { s/^[ ]*public / .globl / s/ , .*$// G s/\n\([ ]*\)public\([ ]\)[^,]*,/\ \1public\2/ P D } s/^[ ]*public / .globl / s/^[ ]*comm / .comm / s/^\([^ ][^ ]*\) proc /\1 : ;proc / / endp / s/^/;/ s/^\([^ ][^ ]*\) label /\1 : ;label / s/^[ ]*even / .even / :equate s/^\([^ ]*\) equ \(.*\) $/#define : \1 \2 / :data s/^[ ]*db / .byte / s/^\([^ ][^ ]*\) db /\1 : .byte / s/^[ ]*dw / .value / s/^\([^ ][^ ]*\) dw /\1 : .value / s/^[ ]*dd / .long / s/^\([^ ][^ ]*\) dd /\1 : .long / /^[ ]*dp / { s/^[ ]*dp / .value / s/$/\/selector of dp pointer/ G s/\n\([ ]*\)dp\([ ]\)/\ \1dd\2/ P D } /^\([^ ][^ ]*\) dp / { s/^\([^ ][^ ]*\) dp /\1: .value / s/$/\/selector of dp pointer/ G s/\n[^ ]*\([ ]*\)dp\([ ]\)/\ \1dd\2/ P D } s/^\([^ ][^ ]*\) struc /\1 : ;struc / s/^\([^ ][^ ]*\) record /\1 : ;record / :modifer s/ : near / /g s/ : far / /g s/ : byte / /g s/ : word / /g s/ : dword / /g s/ short / /g s/ offset / $/g / byte ptr / s/$/?%al?/ s/ byte ptr / /g / word ptr / s/$/?%ax?/ s/ word ptr / /g s/ dword ptr / /g s/ pword ptr / /g :registr s/ e\([abcd]\)x / %e\1x /g s/ \([abcd]\)\([hlx]\) / %\1\2 /g s/ e\([ds]\)i / %e\1i /g s/ \([ds]\)i / %\1i /g s/ e\([bs]\)p / %e\1p /g s/ \([bs]\)p / %\1p /g s/ \([cdefgs]\)s / %\1s /g :bincons s/ \([01][01]*\)b / 0b\1 /g s/ \([0-7][0-7]*\)[oq] / 0\1 /g s/ \([0-9][0-9a-f]*\)h / 0x\1 /g t address :address s/\[/+/g /;/ !s/ ] \. / + /g s/ ]//g s/ %\([^ ]*\) \* \([248]\) + \([^ %][^ ]*\)/ \3 + %\1 * \2/g s/ %\([^ ]*\) + \([^ %][^ ]*\)/ \2 + %\1/g s/ %\([^ ]*\) \* \([248]\) - \([^ %][^ ]*\)/ - \3 + %\1 * \2/g s/ %\([^ ]*\) - \([^ %][^ ]*\)/ - \2 + %\1/g s/ + - / - /g t address s/ \([)(,*/+-]\)/\1/g s/\([)(,*/+-]\) /\1/g s/ :/:/g s/%\([cdefgs]\)s: /%\1s:/g :normliz /: / !s/^\([^ ;#][^ ]*\)/ \1/ /: / !s/^ \([^ +,-]*\)\([+-]\)/ \1 \2/g /: / !s/^ \([^ +,]*\)+%/ \1 +%/g /: / s/^\([^ ]*\) \([^ +,-]*\)\([+-]\)/\1 \2 \3/g /: / s/^\([^ ]*\) \([^ +,]*\)+%/\1 \2 +%/g s/+%\([^ ,]*\)/(%\1)/g s/ +/ /g s/\([:,]\)+/\1/g :operand /[.;#]/ !s/^ \([^ ]*\) \([^,]*\),\([^ ]*\)/ \1 \3,\2/ /[.;#]/ !s/^\([^ ][^ ]*\) \([^ ]*\) \([^,]*\),\([^ ]*\)/\1 \2 \4,\3/ /[.;#]/ !s/^ \([^ ]*\) \([0-9][0-9a-fx]*\)\([ ,]\)/ \1 $\2\3/ /[.;#]/ !s/^\([^ ][^ ]*\) \([^ ]*\) \([0-9][0-9a-fx]*\)\([ ,]\)/\1 \2 $\3\4/ s/(%\([^)+*]*\)+%\([^)*]*\)\*\([248]\))/(%\1,%\2,\3)/g s/(%\([^)+*]*\)\*\([248]\)+%\([^)]*\))/(%\3,%\1,\2)/g s/(%\([^)+*]*\)+%\([^)]*\))/(%\1,%\2)/g s/(%\([^)+*]*\)\*\([248]\))/(,%\1,\2)/g :opcode /[ ,]%[abcd][hl]/ s/$/?%al?/ /[ ,]%[abcd]x/ s/$/?%ax?/ /[ ,]%[ds]i/ s/$/?%ax?/ /[ ,]%[bs]p/ s/$/?%ax?/ /?%al?/ s/^\([^ ]*\) \([^ ]*\) /\1 \2b / /?%ax?/ s/^\([^ ]*\) \([^ ]*\) /\1 \2w / s/^#define:/#define/ s/?%a[xl]?//g :comment s/ *$// x /;/ !s/^.*$// s/\([ ]*\);/;\1;/ s/^[^;]*;// x G s/\n// s/;/\// ************************************************************************END /Roine From mcl.ucsb.edu!uwingcat Thu Jun 8 19:13:32 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJtZh-000fJ2C; Thu, 8 Jun 95 19:13 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id TAA10273; Thu, 8 Jun 1995 19:12:41 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id TAA06728; Thu, 8 Jun 1995 19:13:19 -0700 Message-Id: <199506090213.TAA06728@mcl.mcl.ucsb.edu> Subject: Re: Debate still continues... (fwd) To: ag-directors@krl.caltech.edu Date: Thu, 8 Jun 1995 19:13:19 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 755 > > Ok, I'll upload a .h file when I upload universe.c 0.42 > > Okay - tell me when you do so I know to move it into the programs > directory. FTP is unstable from here (actually, my entire site's unstable), so I'll be "uploading" it to this list instead of the FTP site. > > > ag-fe should > > > be sufficient as this allows us to discuss the api away from directors. > > > > If ag-universe is added to it... > > Should I do this? Or should I just move specific people from ag-universe > also onto the ag-fe list. Up to you folks. I think you should. BTW, can you also remove uwingcat@mcl.ucsb.edu from the lists and replace it with 71044.2164@compuserve.com? mcl.ucsb.edu will not be acessible to me after 6/17, and it may crash before then. From mcl.ucsb.edu!uwingcat Thu Jun 8 19:20:37 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJtgY-000fJ3C; Thu, 8 Jun 95 19:20 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id TAA10667 for ; Thu, 8 Jun 1995 19:19:47 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id TAA08224; Thu, 8 Jun 1995 19:20:25 -0700 Message-Id: <199506090220.TAA08224@mcl.mcl.ucsb.edu> Subject: Re: Debate still continues... (fwd) To: ag-directors@krl.caltech.edu Date: Thu, 8 Jun 1995 19:20:25 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1135 > Agreed. I prefer the idea of circular testing anyways, is cooler > IMHO, as it allows a larger & more predictable surface to shoot against. Ok, we'll do circle-circle collision (Badcoe: do you have code for this?) and tell AS when a collision occurs so AS can update the animation. > Sorry, missed that part (I was in a rush to write a midterm.. > :>), but FE definitely does ALL the redraws itself, ie: universe calls > FE_RedrawScreen, and FE goes to it. Why? Anyother method would be > basically shooting FE in the foot. Agreed. > > > True...BTW, what's the current membership of ag-universe? To my knowledge, > > > everyone on that list who has programmed any part of universe.c is also on > > > this list. > > > > This == directors ? Yes. > Nope... I'm not on Universe, but I'm on directors. Mind you, > Charles just mentioned to me that everyone on directors is now on FE :> Re-read: everyone on ag-universe who has programmed...I didn't mention anyone who was outside of ag-universe who had programmed, neither confirming nor denying their (actually, Jeff's) existence. It is, however, a moot point. From mcl.ucsb.edu!uwingcat Thu Jun 8 19:28:17 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJtmk-000fJ6C; Thu, 8 Jun 95 19:26 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id TAA10987; Thu, 8 Jun 1995 19:26:11 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id TAA09224; Thu, 8 Jun 1995 19:26:49 -0700 Message-Id: <199506090226.TAA09224@mcl.mcl.ucsb.edu> Subject: Re: What's going on currently for me (fwd) To: ag-directors@krl.caltech.edu Date: Thu, 8 Jun 1995 19:26:49 -0700 (PDT) Cc: ag-alife@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 188 > Well, coincidences crop up when you don't expect them, somebody just > posted this sed script on comp.compilers.djgpp [snip] Just OOC, what does this have to do with anything but FE? From mcl.ucsb.edu!uwingcat Thu Jun 8 19:36:29 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJtvv-000fJ7C; Thu, 8 Jun 95 19:36 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id TAA11551 for ; Thu, 8 Jun 1995 19:35:38 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id TAA11249; Thu, 8 Jun 1995 19:36:17 -0700 Message-Id: <199506090236.TAA11249@mcl.mcl.ucsb.edu> Subject: group overlap To: ag-directors@krl.caltech.edu Date: Thu, 8 Jun 1995 19:36:17 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 147 > I think there's a strong alife == universe corellation as well. Well, what are we using ag-universe for? Mainly "physical" effects of alife... From mcl.ucsb.edu!uwingcat Thu Jun 8 19:37:41 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJtx4-000fJ8C; Thu, 8 Jun 95 19:37 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id TAA11612; Thu, 8 Jun 1995 19:36:51 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id TAA11433; Thu, 8 Jun 1995 19:37:29 -0700 Message-Id: <199506090237.TAA11433@mcl.mcl.ucsb.edu> Subject: Collision Detection To: ag-directors@krl.caltech.edu Date: Thu, 8 Jun 1995 19:37:29 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 172 > > > It could, but someone mentioned they'd like ultra fast tests via > > > ASM or something. > > Said tests may soon be eliminated. > Which ones ? The ASM tests. From mcl.ucsb.edu!uwingcat Thu Jun 8 19:39:20 1995 Return-Path: Received: from beauty.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sJtya-000fJ9C; Thu, 8 Jun 95 19:39 PDT Received: from mcl.mcl.ucsb.edu (mcl.mcl.ucsb.edu [128.111.148.100]) by beauty.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) with ESMTP id TAA11665; Thu, 8 Jun 1995 19:38:24 -0700 From: Adrian Tymes Received: by mcl.mcl.ucsb.edu (8.6.12) id TAA11721; Thu, 8 Jun 1995 19:39:02 -0700 Message-Id: <199506090239.TAA11721@mcl.mcl.ucsb.edu> Subject: Re: Debate still continues... (fwd) To: ag-directors@krl.caltech.edu Date: Thu, 8 Jun 1995 19:39:02 -0700 (PDT) Cc: ag-fe@krl.caltech.edu X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 159 > > Ok, I'll upload a .h file when I upload universe.c 0.42 > > > Any idea when that will be? Probably next week, since I'm about to start my final exams. From dl.ac.uk!mbbad Mon Jun 12 05:16:04 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sL8OV-000fJ3C; Mon, 12 Jun 95 05:15 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id NAA16064 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Mon, 12 Jun 1995 13:13:33 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA15747; Mon, 12 Jun 95 13:13:30 +0100 Date: Mon, 12 Jun 1995 13:13:29 +0100 (BST) From: "I. Badcoe" Subject: Re: Debate still continues... (fwd) To: Adrian Tymes Cc: ag-directors@krl.caltech.edu In-Reply-To: <199506090220.TAA08224@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 8 Jun 1995, Adrian Tymes wrote: > Ok, we'll do circle-circle collision (Badcoe: do you have code for this?) No. But I do have sphere-sphere collision. It's really simple guys, there are three approaches: (i) calculate dx*dx + dy*dy (=distance squared) and compare it to (r1+r2)*(r1*r2) ((sum of radii) squared). This is fp-precise and not too expensive (it doesn't use sqrt!). (ii) Cheaper than this (and *much* less accurate) is to use octagons: calculate max(dx,dy)+0.5*min(dx,dy), this gives an 'octagonal distance' between the two centres and compare to (r1+r2). (iii) Somewhere between the two is to limit ourselves to a small number of sizes (say 8) and have a look-up: look-up[size1][size2][abs(dx)][abs(dy)] which gives 0 or 1 depending on whether its a hit or not. This is probably not as bad as it looks, for eg look-up[1][2] and look-ip[2][1] can point to the same array. Personally I'd go with (i) until it's proven too slow. > and tell AS when a collision occurs so AS can update the animation. Badders From undergrad.math.uwaterloo.ca!jmlait Mon Jun 12 10:38:39 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sLDRK-000fJ8C; Mon, 12 Jun 95 10:38 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56844-2>; Mon, 12 Jun 1995 13:36:58 -0400 Date: Mon, 12 Jun 1995 13:36:56 -0400 From: Jeff Lait To: "I. Badcoe" cc: Adrian Tymes , ag-directors@krl.caltech.edu Subject: Re: Debate still continues... (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jun 1995, I. Badcoe wrote: > (i) calculate dx*dx + dy*dy (=distance squared) and compare it to > (r1+r2)*(r1*r2) ((sum of radii) squared). This is fp-precise > and not too expensive (it doesn't use sqrt!). > This is what I also posted when I suggest circle to circle. It's pretty quick, people tend to overreact to multiplications - int mults aren't THAT bad. > (ii) Cheaper than this (and *much* less accurate) is to use octagons: > calculate max(dx,dy)+0.5*min(dx,dy), this gives an 'octagonal > distance' between the two centres and compare to (r1+r2). > I wouldn't go for this. Though it works fine for small radii, it really becomes visible when working with large surfaces. I highly doubt we'll be spending any great portion of time in the circle collision detection code: The majority of collision detection will be spent testing bounding boxes. > (iii) Somewhere between the two is to limit ourselves to a small number > of sizes (say 8) and have a look-up: > > look-up[size1][size2][abs(dx)][abs(dy)] > > which gives 0 or 1 depending on whether its a hit or not. > > This is probably not as bad as it looks, for eg look-up[1][2] and > look-ip[2][1] can point to the same array. > I'd disagree. You're looking at ~256 bytes for a collision between two 16x16's. Then if we have 8 different sized objects, we need 8! different tables to check all combinations of collision. That comes to what, 40000? Or about 10k of tables? After address calculation and the inevitable cache missing, I think we'd be back down to the level of dealing with circles :> - Jeff Lait (SOL) From compuserve.com!71044.2164 Mon Jun 12 12:31:29 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sLFCj-000fJ5C; Mon, 12 Jun 95 12:31 PDT Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id PAA23265; Mon, 12 Jun 1995 15:30:12 -0400 Date: 12 Jun 95 15:27:59 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: Subject: The latest discussions Message-ID: <950612192759_71044.2164_GHI40-1@CompuServe.COM> OOC means (in this case) Out Of Curiosity. FE issues affect everybody, true, but there is a limit to how much it can affect the other groups before it becomes relevant. IMHO, porting to a different platform would be appropriate for ag-fe, but not *quite* relevant to ag-directors. In the circle-circle detection, shouldn't it be (dx*dx)+(dy*dy) ? And should we compare this to a pre-computed (bboxside/2)*(bboxside/2)? From undergrad.math.uwaterloo.ca!jmlait Mon Jun 12 13:35:55 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sLGD8-000fJ5C; Mon, 12 Jun 95 13:35 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56852-2>; Mon, 12 Jun 1995 16:34:40 -0400 Date: Mon, 12 Jun 1995 16:34:33 -0400 From: Jeff Lait To: Adrian Tymes <71044.2164@compuserve.com> cc: ag-directors@krl.caltech.edu Subject: Re: The latest discussions In-Reply-To: <950612192759_71044.2164_GHI40-1@CompuServe.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jun 1995, Adrian Tymes wrote: > OOC means (in this case) Out Of Curiosity. > > FE issues affect everybody, true, but there is a limit to how much it > can affect the other groups before it becomes relevant. IMHO, porting > to a different platform would be appropriate for ag-fe, but not *quite* > relevant to ag-directors. OOC, what prompted this :> > > In the circle-circle detection, shouldn't it be (dx*dx)+(dy*dy) ? > And should we compare this to a pre-computed (bboxside/2)*(bboxside/2)? > dx is the hor distance between the two ships when they are being tested for collision. As a result, it cannot be calculated ahead of time. (r1+r2)**2 refers to the bounding boxes, so we could technically note that: (r1+r2)**2 = r1*r1 + 2*r1*r2 + r2*r2, and here pre calculate r1*r1, r2*r2, and if we only have a finite number of bounding sizes, r1*r2. But I would hold that such precalculation would be a waste of memory - sure it won't take much, but the time we'll be loosing will probably be minimal. I could be wrong though, so we'll find out through actually coding & testing. I suspect. however. that A_life will be taking enough cycles per ship to make these occasional tests negligible. - Jeff Lait (SOL) From dl.ac.uk!mbbad Tue Jun 13 02:22:28 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sLSAy-000fJ7C; Tue, 13 Jun 95 02:22 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id KAA21884 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Tue, 13 Jun 1995 10:20:54 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA23006; Tue, 13 Jun 95 10:20:49 +0100 Date: Tue, 13 Jun 1995 10:20:46 +0100 (BST) From: "I. Badcoe" Subject: Re: Debate still continues... (fwd) To: ag-directors@krl.caltech.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jun 1995, I. Badcoe wrote: > It's really simple guys, there are three approaches: > > (i) calculate dx*dx + dy*dy (=distance squared) and compare it to > (r1+r2)*(r1*r2) ((sum of radii) squared). This is fp-precise ^ ooops, typo, should be '+' Badders From dl.ac.uk!mbbad Tue Jun 13 02:28:46 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sLSGu-000fJ8C; Tue, 13 Jun 95 02:28 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id KAA22298 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Tue, 13 Jun 1995 10:27:01 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA23864; Tue, 13 Jun 95 10:26:59 +0100 Date: Tue, 13 Jun 1995 10:26:58 +0100 (BST) From: "I. Badcoe" Subject: Re: The latest discussions Cc: ag-directors@krl.caltech.edu In-Reply-To: <950612192759_71044.2164_GHI40-1@CompuServe.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 12 Jun 1995, Adrian Tymes wrote: > In the circle-circle detection, shouldn't it be (dx*dx)+(dy*dy) ? Isn't that what I put ? > And should we compare this to a pre-computed (bboxside/2)*(bboxside/2)? That assumes that all the circles are the same size (and only allows for the radius of one of them anyway). (r1+r2)^2 could certainly be precomputed, however, I intended that. Badders From compuserve.com!71044.2164 Tue Jun 13 13:45:13 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sLcpf-000fJ3C; Tue, 13 Jun 95 13:45 PDT Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id QAA05015; Tue, 13 Jun 1995 16:44:00 -0400 Date: 13 Jun 95 16:42:50 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: Subject: Collision Detection Message-ID: <950613204249_71044.2164_GHI102-1@CompuServe.COM> > OOC, what prompted this :> The discussion of an Intel <-> AT&T translator in ag-directors. [discussion about formulas for (r1+r2)**2] When you put it that way, I don't see how pre-calculating (r1*r1) and (r2*r2) gains us anything unless we also pre-calculate (2*r1*r2). Without this last one, we still have two adds and two multiplies, as opposed to one add and one multiply for (r1+r2)**2. Would it save time to skip the bounding box checks entirely and have all collision detections be circle-circle, or not? From undergrad.math.uwaterloo.ca!jmlait Tue Jun 13 16:50:20 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sLfir-000fJ3C; Tue, 13 Jun 95 16:50 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56887-2>; Tue, 13 Jun 1995 19:49:03 -0400 Date: Tue, 13 Jun 1995 19:48:51 -0400 From: Jeff Lait To: Adrian Tymes <71044.2164@compuserve.com> cc: ag-directors@krl.caltech.edu Subject: Re: Collision Detection In-Reply-To: <950613204249_71044.2164_GHI102-1@CompuServe.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 Jun 1995, Adrian Tymes wrote: > > OOC, what prompted this :> > > The discussion of an Intel <-> AT&T translator in ag-directors. > Again, why? The discussion was relevant to non-FE platforms such as universe as it's a bit hard to test the universe code without the FE. And if one cannot assemble the code, then it cannot be used, no? > [discussion about formulas for (r1+r2)**2] > > When you put it that way, I don't see how pre-calculating (r1*r1) and > (r2*r2) gains us anything unless we also pre-calculate (2*r1*r2). Without > this last one, we still have two adds and two multiplies, as opposed to > one add and one multiply for (r1+r2)**2. > Don't forget this is possible (precalculating 2*r1*r2), but how many cycles does a 32bit mul cost? 13-42, exact cost varying depending on what numbers we are multiplying. Most likely closer to 26 for average cases. Compare this with three table lookups, the advantage of tables is still there, but is not overwhelming. > Would it save time to skip the bounding box checks entirely and have all > collision detections be circle-circle, or not? Depends on the sector size. If sectors size is such that having more than one ship per sector is rare, we can get away with the slower circle test right away. However, if a lot of tests are performed which fail, we need the bounding box to get rid of the failures ASAP. - Jeff Lait (SOL) From dl.ac.uk!mbbad Thu Jun 15 02:26:51 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sMBCD-000fJ2C; Thu, 15 Jun 95 02:26 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id KAA11386 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Thu, 15 Jun 1995 10:25:27 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA07134; Thu, 15 Jun 95 10:25:24 +0100 Date: Thu, 15 Jun 1995 10:25:19 +0100 (BST) From: "I. Badcoe" Subject: Re: Collision Detection Cc: ag-directors@krl.caltech.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 13 Jun 1995, Jeff Lait wrote: > On Tue, 13 Jun 1995, Adrian Tymes wrote: > > [discussion about formulas for (r1+r2)**2] > > When you put it that way, I don't see how pre-calculating (r1*r1) and > > (r2*r2) gains us anything unless we also pre-calculate (2*r1*r2). Without > > this last one, we still have two adds and two multiplies, as opposed to > > one add and one multiply for (r1+r2)**2. > Don't forget this is possible (precalculating 2*r1*r2), but how > many cycles does a 32bit mul cost? 13-42, exact cost varying depending on > what numbers we are multiplying. Most likely closer to 26 for average > cases. Compare this with three table lookups, the advantage of tables is > still there, but is not overwhelming. Enough already ! I mis-typed it ! I wanted to precalculate (r1+r2)**2, eg a look-up: summed_radii_2[size1][size2] = {{(r1+r2)*(r1+r2),...}...}; ((r1 * r2) is completely irrelevant :-]) > > Would it save time to skip the bounding box checks entirely and have all > > collision detections be circle-circle, or not? They're practically the same thing, you have to calculate (dx, dy) for the circles so you may as well just check them for bbox before you start squaring things. > Depends on the sector size. If sectors size is such that having > more than one ship per sector is rare, we can get away with the slower > circle test right away. However, if a lot of tests are performed which > fail, we need the bounding box to get rid of the failures ASAP. Well, even if ship-ship interactions are relatively rare, the ssectors still score a lot, for example bullet-ship interactions *must* be highly multiple. > - Jeff Lait (SOL) oh, b.t.w, what's "(SOL)" (apart from the nearest star, that is) ? Badders From undergrad.math.uwaterloo.ca!jmlait Thu Jun 15 08:43:45 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sMH52-000fJ2C; Thu, 15 Jun 95 08:43 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56938-2>; Thu, 15 Jun 1995 11:42:01 -0400 Date: Thu, 15 Jun 1995 11:41:54 -0400 From: Jeff Lait To: "I. Badcoe" cc: ag-directors@krl.caltech.edu Subject: Re: Collision Detection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 15 Jun 1995, I. Badcoe wrote: > > Enough already ! I mis-typed it ! I wanted to precalculate (r1+r2)**2, > eg a look-up: > > summed_radii_2[size1][size2] = {{(r1+r2)*(r1+r2),...}...}; > > ((r1 * r2) is completely irrelevant :-]) You're right.. Don't know why I had it stuck in my mind that we'd need to split up r1/r2 before precalcing. This actually doesn't refer to your typo, BTW, which I didn't even notice :> It refers to the fact that: (r1+r2)**2 = r1*r1 + 2*r1*r2 + r2*r2. > > > > Would it save time to skip the bounding box checks entirely and have all > > > collision detections be circle-circle, or not? > > They're practically the same thing, you have to calculate (dx, dy) for > the circles so you may as well just check them for bbox before you start > squaring things. > So you agree bounding box is still required? > > Depends on the sector size. If sectors size is such that having > > more than one ship per sector is rare, we can get away with the slower > > circle test right away. However, if a lot of tests are performed which > > fail, we need the bounding box to get rid of the failures ASAP. > > Well, even if ship-ship interactions are relatively rare, the ssectors > still score a lot, for example bullet-ship interactions *must* be highly > multiple. > Do we need anything this fancy with bullets? (As in bounding box?) I would suggest treating bullets as point sources, allowing us that much faster bbox tests, in which case it is definitely required that we perform a bounding box test first. - Jeff Lait (SOL) From compuserve.com!71044.2164 Thu Jun 15 13:52:14 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sMLtb-000fJ2C; Thu, 15 Jun 95 13:52 PDT Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id QAA15352; Thu, 15 Jun 1995 16:50:49 -0400 Date: 15 Jun 95 16:48:27 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: Subject: Collision detection Message-ID: <950615204826_71044.2164_GHI51-1@CompuServe.COM> Some bullets may be nearly points, but we will be implementing "proximity" missiles with very large bboxes and very small (actually, mostly black) sprites. The collision queue is not a good idea...what happens if the player is involved in a collision at the bottom of a queue during a time of many collisions? The player could get hit half a second, maybe even a full second after colliding. Pluswhich, collision resolution is partly based on current velocity, etc., and we'd have to store that (about as expensive as the actual collision, I'd think). And what happens if an object dies before its collisions can be resolved (for instance, when it is hit by a volley of bullets and dies from the first one)? From undergrad.math.uwaterloo.ca!jmlait Fri Jun 16 06:25:29 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sMbO8-000fJ2C; Fri, 16 Jun 95 06:24 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56860-2>; Fri, 16 Jun 1995 09:23:07 -0400 Date: Fri, 16 Jun 1995 09:23:01 -0400 From: Jeff Lait To: Adrian Tymes <71044.2164@compuserve.com> cc: ag-directors@krl.caltech.edu Subject: Re: Collision detection In-Reply-To: <950615204826_71044.2164_GHI51-1@CompuServe.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 15 Jun 1995, Adrian Tymes wrote: > Some bullets may be nearly points, but we will be implementing > "proximity" missiles with very large bboxes and very small (actually, > mostly black) sprites. > Okay, still, we should have a 0sized object for standard bullets, after all, the majority of bullets will be of this form. > The collision queue is not a good idea...what happens if the player is > involved in a collision at the bottom of a queue during a time of many > collisions? The player could get hit half a second, maybe even a full > second after colliding. Pluswhich, collision resolution is partly based on > current velocity, etc., and we'd have to store that (about as expensive > as the actual collision, I'd think). And what happens if an object dies > before its collisions can be resolved (for instance, when it is hit by > a volley of bullets and dies from the first one)? I seem to have missed the article that brought up collision queues, but even if we have them, we will be clearing them out quickly, no? It would be ridicolous to leave ANY queue unserviced for 1/2 - 1 second, we should drop the frame rate before that happens! It doesn't matter if you're showing 60 fps if nothings happening on the screen because the queues aren't emptying. - Jeff Lait (SOL) From dl.ac.uk!mbbad Mon Jun 19 06:08:22 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sNgYE-000fJ2C; Mon, 19 Jun 95 06:07 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id OAA12646 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Mon, 19 Jun 1995 14:05:56 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA15979; Mon, 19 Jun 95 14:05:50 +0100 Date: Mon, 19 Jun 1995 14:05:47 +0100 (BST) From: "I. Badcoe" Subject: Re: Collision Detection Cc: ag-directors@krl.caltech.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 15 Jun 1995, Jeff Lait wrote: > On Thu, 15 Jun 1995, I. Badcoe wrote: > > > > Would it save time to skip the bounding box checks entirely and have all > > > > collision detections be circle-circle, or not? > > They're practically the same thing, you have to calculate (dx, dy) for > > the circles so you may as well just check them for bbox before you start > > squaring things. > So you agree bounding box is still required? Not *required* but it should still save us some time. We've already calculated all the numbers we need for it and it's cheeper than the circle-circle comparison. > > > Depends on the sector size. If sectors size is such that having > > > more than one ship per sector is rare, we can get away with the slower > > > circle test right away. However, if a lot of tests are performed which > > > fail, we need the bounding box to get rid of the failures ASAP. > > Well, even if ship-ship interactions are relatively rare, the ssectors > > still score a lot, for example bullet-ship interactions *must* be highly > > multiple. > Do we need anything this fancy with bullets? (As in bounding > box?) I would suggest treating bullets as point sources, allowing us that > much faster bbox tests, in which case it is definitely required that we > perform a bounding box test first. I think we're probably talking slightly at cross purposes. I meant that we still need to keep objects in ssectors in order to know what objects to check for ship-bullet collisions. I expect there's a lot to be saved in letting bullets have their own detection routine. I assume that bullet-bullet collisions are not detected ! Badders From charles Mon Jun 19 08:11:38 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sNiUB-000fJ2C; Mon, 19 Jun 95 08:11 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA30916; Mon, 19 Jun 1995 08:11:00 -0700 Message-Id: <9506191511.AA30916@altair.krl.caltech.edu> Subject: ALife status report... To: ag-directors Date: Mon, 19 Jun 1995 08:11:00 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 383 Greetings, Sorry for missing last weeks report, but a lot of stuff came up for me. Anyway, nothing much at all has gone on in the alife group for the past two weeks. Mostly the members have just been working with universe getting things their nailed down. I think once that's done we'll get the inrush of people and things should get going stronger than ever. --- Charles From post.demon.co.uk!darkin.demon.co.uk!Christian Mon Jun 19 09:51:42 1995 Return-Path: <@post.demon.co.uk:Christian@darkin.demon.co.uk> Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sNk2y-000fJ2C; Mon, 19 Jun 95 09:51 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id aa03896; 19 Jun 95 17:48 +0100 Received: from darkin.demon.co.uk by post.demon.co.uk id aa24476; 19 Jun 95 17:49 +0100 Date: Mon, 19 Jun 1995 16:47:44 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <216@darkin.demon.co.uk> To: ag-directors@alnilam.krl.caltech.edu Subject: X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 67 Hi, Here's the promised call for programmers. Please comment on it, and I'll hack it about before we post it on the newsgroups: Hi, Over the past nine months, a project has been going on over the Internet to produce a completely unique kind of artificial intelligence video game. Programmers, artists, and musicians from as far apart as London, South Africa, and The US are collaborating on a freeware game which will use the latest techniques in genetic programming. The idea is quite simple, a 2D shoot-em-up set in the depths of space. But what makes this game unique is that instead of battling with a series of pre-programmed villains sent into action by the programmers, the player in this game will face opponents which have EVOLVED on their own. They will have developed their own strategies for survival, their own weaponry, and their own behaviour. They will also be constantly reproducing, and evolving further. Each copy of the game will be completely unique as soon as it is played, as the opponents will adjust to counter every player's style. The graphics for the enemies will be constantly changing, and the music will evolve as the game is played. In addition, evolved enemies will be saved to disk, and may be swapped from one game to another (possibly via the Internet) creating a world-wide breeding programme that will (hopefully) be larger than any previous experiment in genetic computing. The group responsible for the game (and there are currently about 20 of us) comprise many people who are actively involved in AI research all over the world, as well as many experienced games programmers. We have been working out our approach to the problems, and the style of the game for many months now, and are now at the point where we will soon be ready to start programming. We are looking for volunteers to get involved in the programming stage. If you're interested in the idea, and have particular skills in programming (games, AI or both), music, graphics, or anything else you think might be useful, please contact gtaylor@galaxy.csc.calpoly.edu or visit our HTTP site (HTTP://www.krl.caltech.edu/~charles/alife-game>) Thanks! ==================================================================== :From the beginning, the video game has been a battle between programmer and player. Same old ideas. Same old game-play. Same old enemies. P R O J E C T V O N N E W M A N Today old order breaks down. Today there is a new force. P R O J E C T V O N N E W M A N Today the machine takes control. --------------------------------------------------------------------- -- Christian Darkin From compuserve.com!71044.2164 Mon Jun 19 15:50:47 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sNp6y-000fJ2C; Mon, 19 Jun 95 15:16 PDT Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id RAA18675; Mon, 19 Jun 1995 17:59:47 -0400 Date: 19 Jun 95 17:58:18 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: "INTERNET: ag-directors@krl.caltech.edu" Subject: Re: Collision Detection Message-ID: <950619215818_71044.2164_GHI62-1@CompuServe.COM> >I think we're probably talking slightly at cross purposes. I meant that >we still need to keep objects in ssectors in order to know what objects >to check for ship-bullet collisions. I expect there's a lot to be saved >in letting bullets have their own detection routine. Actually, no. I've already examined it, and as far as I can tell, it is faster to use the same collision detection routine for all objects, since it eliminates another check (if type==BULLET then...else if type==ASTEROID then...) if no collision occurs. >I assume that bullet-bullet collisions are not detected ! They are. This allows for point defense (a la Star Control 2). From charles Mon Jun 19 16:02:08 1995 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sNppV-000fJ2C; Mon, 19 Jun 95 16:02 PDT Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/21Mar95-1007AM) id AA29461; Mon, 19 Jun 1995 16:01:09 -0700 Message-Id: <9506192301.AA29461@rigel.krl.caltech.edu> Subject: Re: your mail To: ag-directors Date: Mon, 19 Jun 1995 16:01:09 -0800 (PDT) From: "Splinterwood" In-Reply-To: <216@darkin.demon.co.uk> from "Christian Darkin" at Jun 19, 95 04:47:44 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 492 [huge munch] > contact gtaylor@galaxy.csc.calpoly.edu or visit our HTTP site > (HTTP://www.krl.caltech.edu/~charles/alife-game>) Greg is supposed to be away for a while I believe... since I'm managing the lists I'd be willing to just take names to add to them (Greg would just bounce them to me anyway if all they wanted was to be added). Any questions people have about the specific groups, I'll direct to the co-ordinator of that group if its okay with everyone else. --- Charles From undergrad.math.uwaterloo.ca!jmlait Mon Jun 19 20:17:10 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sNtoF-000fJ2C; Mon, 19 Jun 95 20:17 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56860-2>; Mon, 19 Jun 1995 23:15:15 -0400 Date: Mon, 19 Jun 1995 23:15:05 -0400 From: Jeff Lait cc: ag-directors@krl.caltech.edu, FE-ALL To: ag-directors@krl.caltech.edu, FE-ALL Subject: Are Bullets Special? In-Reply-To: <950619215818_71044.2164_GHI62-1@CompuServe.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > They are. This allows for point defense (a la Star Control 2). How? To allow this one would either have to allow lasers or assume the bullets can be aimed with sufficient precision to intersect the path of another bullet. If you're allowing lasers, better tell FE soon :> I would assume bullets will be small, fast moving, projectiles, appearing as single dots on the VDU. Interaction between bullets will be highly unlikely at best & probably costly when people start machine gunning (I know I as a user wouldn't want to have a small on screen bullet limit!). Larger, slow moving, possible intellegent, `bullets' should be implemented as drones/missiles: ie: another alien ship with all normal alien ship properties. I would further suggest segregating bullets from the rest of the objects. Ie: Keep a seperate list of bullets. This allows one to avoid doing any extra compares to see if it's a ship-bullet collision and hence if special bullet tests are required. Also, it provides a clean way of ignoring bullet/bullet interaction without invoking extra compares. - Jeff Lait (SOL) From phil.ruu.nl!faassen Tue Jun 20 11:11:58 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sO7m5-000fJ2C; Tue, 20 Jun 95 11:11 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id UAA23402 for ; Tue, 20 Jun 1995 20:10:04 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id UAA16129 for ag-directors@alnilam.krl.caltech.edu; Tue, 20 Jun 1995 20:10:02 +0200 From: Martijn Faassen Message-Id: <199506201810.UAA16129@laurel.stud.phil.ruu.nl> Subject: Re: call for participants To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 20 Jun 1995 20:10:02 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 618 > > > Hi, > > Over the past nine months, a project has been going on over the Internet to > produce a completely unique kind of artificial intelligence video game. > > Programmers, artists, and musicians from as far apart as London, South Africa, > and The US are collaborating on a freeware game which will use the latest Hey! the Netherlands too! :) > P R O J E C T V O N N E W M A N Von Neumann. :) he was a real scientist, btw. Anyway, I'm too tired to comment on this further (I had a final today and not much sleep :) today, but I'll do so soon. Looks good, though. Martijn From undergrad.math.uwaterloo.ca!jmlait Tue Jun 20 18:07:12 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sOEG4-000fJ2C; Tue, 20 Jun 95 18:07 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56835-1>; Tue, 20 Jun 1995 21:05:13 -0400 Date: Tue, 20 Jun 1995 21:04:58 -0400 From: Jeff Lait To: Martijn Faassen cc: AG Directors Subject: Re: call for participants In-Reply-To: <199506201810.UAA16129@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 20 Jun 1995, Martijn Faassen wrote: > > Hi, > > > > Over the past nine months, a project has been going on over the Internet to > > produce a completely unique kind of artificial intelligence video game. > > > > Programmers, artists, and musicians from as far apart as London, South Africa, > > and The US are collaborating on a freeware game which will use the latest > > Hey! the Netherlands too! :) And while you're being all inclusive, don't forget those of us up in Canada!!! > > > P R O J E C T V O N N E W M A N This last bit is real cool! - Jeff Lait (SOL) From compuserve.com!71044.2164 Tue Jun 20 23:59:58 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-3.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sOJlO-000fJ2C; Tue, 20 Jun 95 23:59 PDT Received: by arl-img-3.compuserve.com (8.6.10/5.950515) id CAA20576; Wed, 21 Jun 1995 02:58:13 -0400 Date: 21 Jun 95 02:55:08 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: Subject: Re: Are Bullets Special? Message-ID: <950621065507_71044.2164_GHI44-1@CompuServe.COM> There are a couple of mitigating factors here: 1: Some bullets will be "proximity detonated", meaning that if they are fired in the vicinity of an incoming bullet, they'll blow up. 2: Short-lived, short-ranged machine guns are a perfect form of "point defense"...the short lifespan would be needed to allow the high rate of fire. Not every incoming bullet would be hit, but this would hit some of the incoming bullets. From dl.ac.uk!mbbad Wed Jun 21 08:50:37 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sOS2C-000fJ2C; Wed, 21 Jun 95 08:49 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id QAA29265 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Wed, 21 Jun 1995 16:47:58 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@krl.caltech.edu id AA16962; Wed, 21 Jun 95 16:47:55 +0100 Date: Wed, 21 Jun 1995 16:47:54 +0100 (BST) From: "I. Badcoe" Subject: Re: Collision Detection Cc: "INTERNET: ag-directors@krl.caltech.edu" In-Reply-To: <950619215818_71044.2164_GHI62-1@CompuServe.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 19 Jun 1995, Adrian Tymes wrote: > >I think we're probably talking slightly at cross purposes. I meant that > >we still need to keep objects in ssectors in order to know what objects > >to check for ship-bullet collisions. I expect there's a lot to be saved > >in letting bullets have their own detection routine. > Actually, no. I've already examined it, and as far as I can tell, it is faster > to use the same collision detection routine for all objects, since it eliminates > another check (if type==BULLET then...else if type==ASTEROID then...) if no > collision occurs. > >I assume that bullet-bullet collisions are not detected ! > They are. This allows for point defense (a la Star Control 2). I don't think bullet-bullet collisions are a good idea, bullet-missile and missile-missile collisions are OK but I think we should have a bullet as a "zero-size" projectile. After all, if you and I spray machine-gun fire at each other from reasonable range (again :-), what are the chances of two bullets colliding, pretty small I'd guess. And space is bigger. *Plus*, I doubt that the AL-Engine could possible be run fast enough for a probe to be able to target a hail of bullets. Zero-size bullets are not bad for game-balance, either, because they're harder to defend against *but* far lower damage relative to a missile. Also, there doesn't have to be an extra check in the detection, I think a size-zero object will be happily detected when we are checking for collisions with a larger object, and if we've done that, we don't have to check for collisions with the bullets themselves, eg: for (all probes) { col_detect_with(probes) col_detect_with(missiles) col_detect_with(asteroids) col_detect_with(bullets) } for (all missiles) { col_detect_with(missiles) col_detect_with(asteroids) col_detect_with(bullets) } for (all asteroids) { col_detect_with(asteroids) col_detect_with(bullets) } /* no need to search with bullets as already done */ Badders From undergrad.math.uwaterloo.ca!jmlait Wed Jun 21 11:30:24 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sOUXW-000fJ3C; Wed, 21 Jun 95 11:30 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56867-3>; Wed, 21 Jun 1995 14:28:25 -0400 Date: Wed, 21 Jun 1995 14:28:19 -0400 From: Jeff Lait To: Adrian Tymes <71044.2164@compuserve.com> cc: ag-directors@krl.caltech.edu Subject: Re: Are Bullets Special? In-Reply-To: <950621065507_71044.2164_GHI44-1@CompuServe.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 21 Jun 1995, Adrian Tymes wrote: > There are a couple of mitigating factors here: > > 1: Some bullets will be "proximity detonated", meaning that if they are fired in > the vicinity of an incoming bullet, they'll blow up. > I would claims something like this should be implemented as a missile or drone. > 2: Short-lived, short-ranged machine guns are a perfect form of "point > defense"...the short lifespan would be needed to allow the high rate of fire. > Not every incoming bullet would be hit, but this would hit some of the incoming > bullets. > I would disagree. Have you ever tried to shoot a bullet out of the air with another bullet? :> I would think it would seem a bit silly to the player. Missiles, sure. Bullets, no. Starcontrols point defense worked primarily because they used lasers: removing all messy calculations of trajectories etc. - Jeff Lait (SOL) From compuserve.com!71044.2164 Thu Jun 22 10:02:53 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sOpeT-000fJ2C; Thu, 22 Jun 95 10:02 PDT Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id NAA06509; Thu, 22 Jun 1995 13:01:06 -0400 Date: 22 Jun 95 12:56:43 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: Subject: Re: Collision Detection Message-ID: <950622165643_71044.2164_GHI53-2@CompuServe.COM> >I don't think bullet-bullet collisions are a good idea, bullet-missile >and missile-missile collisions are OK but I think we should have a bullet >as a "zero-size" projectile. After all, if you and I spray machine-gun >fire at each other from reasonable range (again :-), what are the chances >of two bullets colliding, pretty small I'd guess. And space is bigger. True, but when you consider all of the bullets, at least a few of them will probably hit each other. >*Plus*, I doubt that the AL-Engine could possible be run fast enough for >a probe to be able to target a hail of bullets. It sees a hail of bullets coming in and fires in that direction without specifically targetting the hail. >Also, there doesn't have to be an extra check in the detection, I think a >size-zero object will be happily detected when we are checking for >collisions with a larger object, and if we've done that, we don't have to >check for collisions with the bullets themselves, eg: [post-movement collision detection deleted] If we do collision detection after movement, this would be a good method of implementing it. From compuserve.com!71044.2164 Thu Jun 22 10:03:20 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sOpem-000fJ3C; Thu, 22 Jun 95 10:03 PDT Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id NAA06564; Thu, 22 Jun 1995 13:01:25 -0400 Date: 22 Jun 95 12:57:15 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: Subject: Re: Re: Are Bullets Special? Message-ID: <950622165715_71044.2164_GHI53-3@CompuServe.COM> >> There are a couple of mitigating factors here: >> >> 1: Some bullets will be "proximity detonated", meaning that if they are >> fired in the vicinity of an incoming bullet, they'll blow up. >> >> 2: Short-lived, short-ranged machine guns are a perfect form of "point >> defense"...the short lifespan would be needed to allow the high rate of >> fire. Not every incoming bullet would be hit, but this would hit some >> of the incoming bullets. >All this beggs the question of what happens when a bullet is hit. What's >the effect? >Do we: >Simply change the shell's momentum - deflect it? >Cause the bullet to detonate prematurely? >Destroy the shell without detonating it? >Just reduce its effectiveness? The effect is the same as if the bullet had hit something. With plain explosive bullets, this means that the bullet explodes when something else hits it or when it hits something else. >What about 'freindly fire' - Two bullets from the same probe colliding? >This would happen pretty regularly if a probe had two sets of machine >guns, one firing faster bullets than the other along the same path. Coming out of the same point of the probe? Hmm...this would be a problem. But what about rapid-fire prox. bullets/missiles? Wouldn't these also pose a problem? >And should the effect be the same on every kind of bullet/bomb/particle >beam/flame thrower/whatever that appears in the game? "Detonate" on collision, depending on exactly what "detonate" means to the bullet's warhead. >I'm not saying we shouldn't have bullet,bullet collisions, but it needs >thought. >-- >Christian Darkin From undergrad.math.uwaterloo.ca!jmlait Fri Jun 23 00:29:45 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sP3BI-000fJ2C; Fri, 23 Jun 95 00:29 PDT Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56856-3>; Fri, 23 Jun 1995 03:27:37 -0400 Date: Fri, 23 Jun 1995 03:27:25 -0400 From: Jeff Lait To: Adrian Tymes <71044.2164@compuserve.com> cc: ag-directors@krl.caltech.edu Subject: Re: Collision Detection In-Reply-To: <950622165643_71044.2164_GHI53-2@CompuServe.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 22 Jun 1995, Adrian Tymes wrote: > True, but when you consider all of the bullets, at least a few of them will > probably hit each other. > Yes, a few would. But a very few. Is it worth it to use the extra cycles for the one or two bullets per frame which collide? > >*Plus*, I doubt that the AL-Engine could possible be run fast enough for > >a probe to be able to target a hail of bullets. > > It sees a hail of bullets coming in and fires in that direction without > specifically targetting the hail. > Great. So we have two hails of bullets on intercept courses, with collisions between them all checked every frame. It is not just AL here, but the collision detection. Many of the `fancy' bullets which require this sort of thing could be IMHO implemented as special cases, generic machine gun bullets by definition are numerous, very small, and fast moving. In other words, poor candidates for collision detection (a great majority of the collisions will simply `miss', as the bullets leapfrog over each other as they are probably moving more than their length in a single frame) - Jeff Lait (SOL) From phil.ruu.nl!faassen Fri Jun 23 06:08:49 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sP8TP-000fJ2C; Fri, 23 Jun 95 06:08 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id PAA06907 for ; Fri, 23 Jun 1995 15:06:52 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id PAA02242 for ag-directors@alnilam.krl.caltech.edu; Fri, 23 Jun 1995 15:06:43 +0200 From: Martijn Faassen Message-Id: <199506231306.PAA02242@laurel.stud.phil.ruu.nl> Subject: Re: Collision Detection To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Fri, 23 Jun 1995 15:06:42 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2299 > On Thu, 22 Jun 1995, Adrian Tymes wrote: > > > True, but when you consider all of the bullets, at least a few of them will > > probably hit each other. > > > Yes, a few would. But a very few. Is it worth it to use the > extra cycles for the one or two bullets per frame which collide? > > > >*Plus*, I doubt that the AL-Engine could possible be run fast enough for > > >a probe to be able to target a hail of bullets. > > > > It sees a hail of bullets coming in and fires in that direction without > > specifically targetting the hail. That's indeed something a probe might do. But.. > Great. So we have two hails of bullets on intercept courses, > with collisions between them all checked every frame. It is not just AL > here, but the collision detection. Many of the `fancy' bullets which > require this sort of thing could be IMHO implemented as special cases, > generic machine gun bullets by definition are numerous, very small, and > fast moving. In other words, poor candidates for collision detection > (a great majority of the collisions will simply `miss', as the bullets > leapfrog over each other as they are probably moving more than their > length in a single frame) > - Jeff Lait (SOL) Yes, checking collisions for normal bullets (with each other) may be too much. Imagine bullets are cheap and much used. Imagine we have a 100 probes in the system (100 is a totally arbitrary guess here :). Now, it sounds concievable that if bullets are cheap, they'll be used a lot. So, there may be about a factor 10 or so bullets more in the system. A 1000 bullets processed each frame. I have no idea how much collision detection is going to add to the CPU cost, as we're dealing with sectors and so on it may not even be that incredibly much more. So, I suggest a compromise: let's wait and see. Code Universe in such a way we can turn intra bullet collision detection on and off. Then see which works best. Maybe make it another option we can turn on and off. Is that okay with everybody? Martijn (who now is supposed to study for his final monday..) -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From undergrad.math.uwaterloo.ca!jmlait Fri Jun 23 10:56:17 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sPCxe-000fJ2C; Fri, 23 Jun 95 10:56 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56844-3>; Fri, 23 Jun 1995 13:54:19 -0400 Date: Fri, 23 Jun 1995 13:54:13 -0400 From: Jeff Lait cc: AG Directors To: AG Directors Subject: Re: Collision Detection In-Reply-To: <199506231306.PAA02242@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 23 Jun 1995, Martijn Faassen wrote: > 1000 bullets processed each frame. I have no idea how much collision detection > is going to add to the CPU cost, as we're dealing with sectors and so on it > may not even be that incredibly much more. So, I suggest a compromise: This would be the case iff the bullets are randomly distributed throughout the universe. But they won't be, by your earlier statement we will have hails of bullets shot out to try and take down other hails of bullets. Thus the sectors will not help us much, and we must pay the full price of O(N^2) comparisons. > let's wait and see. Code Universe in such a way we can turn intra bullet > collision detection on and off. Then see which works best. Maybe make it > another option we can turn on and off. Is that okay with everybody? > Trouble with this is that if we have detection off, it would be best to use 0 sized bullets, thereby streamlining all bullet tests (As the bullets will be treated as special objects as per Badcoe's suggestion, this would not require any extra time to implement) With it on, however, bullets must have a non 0 size. > Martijn (who now is supposed to study for his final monday..) > - Jeff Lait (SOL (Who is now done his last midterm!) From charles Fri Jun 23 10:59:18 1995 Return-Path: Received: from regulus.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sPD0e-000fJ2C; Fri, 23 Jun 95 10:59 PDT Received: by regulus.krl.caltech.edu; (5.65/1.1.8.2/07Apr95-0112PM) id AA03721; Fri, 23 Jun 1995 10:51:56 -0700 Message-Id: <9506231751.AA03721@regulus.krl.caltech.edu> Subject: Re: Collision Detection To: ag-directors Date: Fri, 23 Jun 1995 10:51:56 -0800 (PDT) From: "Splinterwood" In-Reply-To: from "Jeff Lait" at Jun 23, 95 01:54:13 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 770 > > 1000 bullets processed each frame. I have no idea how much collision detection > > is going to add to the CPU cost, as we're dealing with sectors and so on it > > may not even be that incredibly much more. So, I suggest a compromise: > > This would be the case iff the bullets are randomly distributed > throughout the universe. But they won't be, by your earlier statement we > will have hails of bullets shot out to try and take down other hails of > bullets. Thus the sectors will not help us much, and we must pay the > full price of O(N^2) comparisons. My point was that it doesn't even matter if we have two hails of bullets coming at each other; within a single hail we'd have to check for all posisble collisions between bullets! --- Charles From compuserve.com!71044.2164 Fri Jun 23 13:29:58 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sPFMN-000fJ3C; Fri, 23 Jun 95 13:29 PDT Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id QAA25672; Fri, 23 Jun 1995 16:28:01 -0400 Date: 23 Jun 95 16:25:52 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: Cc: Subject: Re: Collision Detection Message-ID: <950623202552_71044.2164_GHI137-1@CompuServe.COM> >> let's wait and see. Code Universe in such a way we can turn intra bullet >> collision detection on and off. Then see which works best. Maybe make it >> another option we can turn on and off. Is that okay with everybody? >> > Trouble with this is that if we have detection off, it would be >best to use 0 sized bullets, thereby streamlining all bullet tests (As >the bullets will be treated as special objects as per Badcoe's >suggestion, this would not require any extra time to implement) With it >on, however, bullets must have a non 0 size. Why? I don't see why bbox-bbox and circle-circle collisions can't check to see if points (side = 0 / radius = 0) lie in bboxes or circles. >> Martijn (who now is supposed to study for his final monday..) >> > > - Jeff Lait (SOL (Who is now done his last midterm!) - Adrian (who finished his finals last week, and is now job-hunting) From dl.ac.uk!mbbad Mon Jun 26 05:20:13 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sQD8y-000fJ3C; Mon, 26 Jun 95 05:20 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id NAA10738 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Mon, 26 Jun 1995 13:17:58 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-universe@krl.caltech.edu id AA11699; Mon, 26 Jun 95 13:17:54 +0100 Date: Mon, 26 Jun 1995 13:17:51 +0100 (BST) From: "I. Badcoe" Subject: Re: Collision Detection Cc: ag-universe@krl.caltech.edu, ag-directors@krl.caltech.edu In-Reply-To: <950623202552_71044.2164_GHI137-1@CompuServe.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 23 Jun 1995, Adrian Tymes wrote: > > Trouble with this is that if we have detection off, it would be > >best to use 0 sized bullets, thereby streamlining all bullet tests (As > >the bullets will be treated as special objects as per Badcoe's > >suggestion, this would not require any extra time to implement) With it > >on, however, bullets must have a non 0 size. > Why? I don't see why bbox-bbox and circle-circle collisions can't check to see > if points (side = 0 / radius = 0) lie in bboxes or circles. It'll do a zero-size collision with finite-sezed object but a sero-size with a zero-size leaves me scratching my head. However, I don't think that was the point, the point is that if we do CD by classes (player, probes, eggs, missiles, asteroids ...) then we can save something 'cos (i) certain classes can be neglected, and (ii) we handle the different types of collision in with different loops (rather than deciding the collision type *inside* a loop). The bullet-bullet collision is an example of case (i) when turned off but has to be considered when turned on. Anyway, here's a long list of why no bullet-bullet collisions is a good thing: (i) Bullets are simpler than other objects (they have properties (x,y,z), (dx,dy,dz), age) so we can save a lot by storing them as a simpler struct. (ii) If we CD them there's a limit to haw many we can have, if we don't CD them we can have far more (giving more strategies to the probes). Also, if there is a top limit to the number of bullets in play, we have to find a way to stop the probes exceding that. (iii) Bullet-Bullet-CD would be a *lot* of CPU for very little effect on the game. I still think CPU is going to be our biggest headache. (iv) Any special cases are still possible, but they're of class 'missile' and not bullet. They need not look different to the user. (v) A 'Hail of bullets' comming from a single source will all be in the same ssector *but* probably cannot collide ('cos they're on parallel or diverging courses), however, I can't think of a (simple) way to tell the game not to CD them against each other. (vi) We have to get the rudiments of the universe working A.S.A.P 'cos we need some details of it to plug into the ALife engine *before* we can test it. We also need the universe-FE interfaces firmed up 'cos we need to see any problems *before* too much additional code gets written. Therefor we should K.I.S.S (Keep It Simple, Stupid!) for the moment and only add any 'niceties' when we've got the basics in place. Options that can be turned on and off are 'niceties' (except debugging options, of course). > - Jeff Lait (SOL (Who is now done his last midterm!) > - Adrian (who finished his finals last week, and is now job-hunting) Badders, (who finished his finals in 1985 and now has a job, a house, a car, a wife and a baby (but, oddly, hasn't got any older)) From compuserve.com!71044.2164 Wed Jun 28 10:27:04 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sR0sb-000fJ2C; Wed, 28 Jun 95 10:26 PDT Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id NAA21518; Wed, 28 Jun 1995 13:24:17 -0400 Date: 28 Jun 95 13:23:18 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Universe Cc: AG-Directors Subject: universe.c 0.42 Message-ID: <950628172318_71044.2164_GHI93-2@CompuServe.COM> /* Universe code version 0.42, copyright us 6/27/1995 */ #include "universe.h" /* UN_CheckObject is called for each object each 'tick' */ UN_CheckObject (object *obj) { curwhat = obj->what; /* what the object is stored in curwhat */ tempx = obj->x/SUBSIZE; /* store subsector temporarily */ tempy = obj->y/SUBSIZE; curpic = 0; switch (curwhat) /* get keys & virtual keys */ { case PLAYER: /* this is the player */ obj->extra.animate.actions = FE_GetKeys(); /* get the real keypresses */ break; /* note: this makes all objects of type PLAYER act in exactly the same ** way...we might want to have some other means of controlling PLAYER ** objects that aren't currently being controlled by the player. */ case PROBE: /* this is a probe */ probes_exist = 1; /* there's still probes in the battlefield */ /* get the virtual keypresses from a short AI routine - real alife work is done elsewhere */ obj->extra.animate.actions = AI_GetKeys(obj); break; /* case missile (probe remote control, and standard control routines) */ /* case SUPPLY */ } /* end of switch(curwhat) */ if (curwhat <= MISSILE) /* this is an animate object */ { if (obj->extra.animate.actions & THRUST) /* forward thrust */ { curthrust = obj->extra.animate.thrust; if (obj->energy - thrustcost[curthrust] >= 0) /* if enough energy */ { /* assuming navigation system with north = 0, clockwise increase calculate vector changes */ obj->velx += (curthrust/obj->mass) * sin[obj->facdir]; obj->vely += (curthrust/obj->mass) * cos[obj->facdir]; /* energy cost of this thrust */ obj->energy -= thrustcost[curthrust]; /* lookup for thrustcost */ curpic=THRUSTPIC; } else /* not enough energy for thrust */ { /* FE call here for thrust fail art/sound, currently none */ if (curwhat == PROBE) { /* hardware interrupt for AI note that hardware interrupts calls don't do anything directly; the interrupt is just registered, later the interrupt handler will handle it */ AI_interrupt(obj, THRUST_FAIL); } } /* end of not enough energy code */ } /* end of THRUST code */ else if (obj->extra.animate.actions & BRAKE) /* backward thrust */ { curthrust = obj->extra.animate.thrust; if (obj->energy - thrustcost[curthrust] >= 0) /* if enough energy */ { /* assuming navigation system with north = 0, clockwise increase calculate vector changes */ obj->velx -= (curthrust/obj->mass) * sin[obj->facdir]; obj->vely -= (curthrust/obj->mass) * cos[obj->facdir]; /* energy cost of this brake thrust */ obj->energy -= thrustcost[curthrust]; /* lookup for thrustcost */ curpic=BRAKEPIC; } else /* not enough energy for brake thrust */ { /* FE call here for brake thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, BRAKE_FAIL); /* hardware interrupt */ } } /* end of not enough energy code */ } /* end of BRAKE code - end of THRUST/BRAKE code */ /* NOTE: we might want to kick out different turn speeds, and use a standard turnspeed instead for each object */ if (obj->extra.animate.actions & LEFT) /* turn to the left */ { /* turning to left, so counterclockwise, means decreasing angle */ /* % operator doesn't work here, because when turning left the facdir will never rise above 255. Instead code is needed to handle facdir < 0. This code will break with turnspeed > 256 :) */ obj->facdir = (obj->facdir - obj->extra.animate.turn); if (obj->facdir < 0) { obj->facdir += 256; } /* alternatively (if faster?) use: obj->facdir = (256 + (obj->facdir - obj->extra.animate.turn)) % 256 */ } /* end of LEFT code */ else if (obj->extra.animate.actions & RIGHT) /* turn to the right */ { /* turning to the right, so clockwise, means increasing angle */ /* % operator is used */ obj->facdir = (obj->facdir + obj->extra.animate.turn) % 256; } /* end of RIGHT code */ /* target code for player only...probes handle this differently, and this ** only allows the player to target things in the 11*11 subsectors nearest to ** the subsector that the player is in, since this is what will be on the ** player's screen...and while we could allow the player to target anything, ** the player will probably not want to spend the time to cycle through ** everything that's out of sight to target an incoming food source */ /* note: this has bugs in it (especially the "last target" part), ** so IGNORE the target code for now. */ if (obj->actions & NEXTTARGET) { /* cycle to next target */ if ((obj->extra.animate.target)->next_hash!=NULL) obj->extra.animate.target= (obj->extra.animate.target)->next_hash; else { /* search through sectors to find a target */ long x=((obj->extra.animate.target)->x/SUBSIZE), y=((obj->extra.animate.target)->y/SUBSIZE); x++; if (x>tempx+5) {x=tempx-5; y++;} if (y>tempy+5) y=tempy-5; while (sector[(x+NUMSUBS)%NUMSUBS][(y+NUMSUBS)%NUMSUBS]==NULL) { x++; if (x>tempx+5) { x=x-11; y++; if (y>tempy+5) y=y-11;} } obj->extra.animate.target= sector[(x+NUMSUBS)%NUMSUBS][(y+NUMSUBS)%NUMSUBS]; } } /* sorry for the tab shifts above, but I don't know if I can break up the ** sector[formula][formula] without inducing a parsing error */ /* end of "next target" code */ else if (obj->actions & LASTTARGET) { /* find previous target */ object *tar=obj->extra.animate.target; if (tar->prev_hash!= &(sector[tar->x >> SUBPOWER][tar->y >> SUBPOWER])) obj->extra.animate.target= *(tar->prev_hash); else { /* cycle through sectors to find previous target */ long x=(tar->x >> SUBPOWER), y=(tar->y >> SUBPOWER); x--; if (xextra.animate.target= sector[(x+NUMSUBS)%NUMSUBS][(y+NUMSUBS)%NUMSUBS]; } } /* end of "last target" code; also end of player's "change target" code */ /* need to add in FIRE for PLAYER/PROBE */ /* need to add in cycle weapon code for PLAYER/PROBE */ /* one possibility: have objects outside of the objects list be the prototypes for each weapon, with next_hash/prev_hash forming a circular double-linked list for each object; cycle weapon would then get the next (or previous) object on that list, while fire would merely make a duplicate of that weapon into the objects list, editing velocity, position, and (if needed) target as needed */ /* need to add in energy to shield code for PLAYER/PROBE/SUPPLY */ /* need to add in breed stuff */ /* need to add in pick up/drop */ /* these last two could merely set flags (for instance, object->extra.animate.actions & BREED) that could be checked if the object bumps into another object, since fertilization and grabbing will only be processed when an object that is trying to do that comes into contact with another one */ } /* end if animate */ if (user->extra.animate.target == obj) curpic += TARGETPIC; AS_SetPic(obj->pic,(curpic)&((obj->facdir + 256)%256)); /* Sets the current picture so FE can just display it if it is visible, also allows cycling of colors. We may want to move this to after the collision detection. */ /* Movement update */ obj->x += obj->velx; obj->y += obj->vely; /* torrodial space implementation */ obj->x = obj->x & MAX_X; /* note that MAX_X should be total amount of */ obj->y = obj->y & MAX_Y; /* horizontal universe points, not the maximum value x can take (which is one less), and MAX_Y should be similar for vertical universe points */ /* did this object move into a different subsector? */ subx = obj->x >> SUBPOWER; suby = obj->y >> SUBPOWER; if ((subx != tempx) || (suby != tempy)) UN_Shift(subx, suby, obj); /* update sector lists */ /* detect collisions */ xh = ((obj->x - SUBSIZE + 1) >> SUBPOWER); yh = ((obj->y - SUBSIZE + 1) >> SUBPOWER); for (txh=xh;txh What variables are what: (Z=x or y) Zh = the Z coordinate of the topmost/leftmost subsector to check tZh = the Z coorindate of the subsector currently being checked Note that Zh and tZh may be negative or greater than 64, so checks against sector[txh][tyh] are not ok. ttZh = tZh normalized to 0 <= ttZh < 64 This allows checks against sector[ttxh][ttyh] . dZ = the difference in the Z coordinates of obj and this_obj, as adjusted for torriodal space (we can tell if we need to adjust, and if so, how, by comparing tZh and ttZh. If tZh==ttZh, no adjustment is needed. If tZhttZh, add MAX_Z to obj's Z coordinate before checking. Note: we may want to have one standard bboxside for all objects...this would get rid of four indirect references per collision, and it would avoid the problem of a small obj moving into this_obj's bbox but not colliding because this_obj is not in obj's bbox, and this_obj moving its bbox away from obj before colliding. If we do this, then the pixel maps would still come in fixed sizes (the largest confined to a circle no more than SUBSIZE in diameter, as is the current plan anyway), but this problem would be avoided. */ while (this_obj!=NULL) { if ((this_obj==obj) || (this_obj->shield<=0)) continue; /* Can't collide with yourself, and a bullet's explosion can only hit one ** other object per object that the bullet contained. */ if (ttxh==txh) dx = obj->x - this_obj->x; else if (ttxhx - this_obj->x - (MAX_X); else dx = (MAX_X) + obj->x - this_obj->x; if (ttyh==tyh) dy = obj->y - this_obj->y; else if (ttyhy - this_obj->y - (MAX_Y); else dy = (MAX_Y) + obj->y - this_obj->y; if ( (dx < this_obj->bboxside) && (dx > obj->bboxside) && (dy < this_obj->bboxside) && (dy > obj->bboxside) && ((dx*dx)+(dy*dy) < ((this_obj->bboxside + obj->bboxside)**2)) ) /* we have a collision between obj and this_obj, so handle it */ { if ((this_obj->what == BULLET) || (this_obj->what == MISSILE) || (obj->what == BULLET) || (obj->what == MISSILE)) { if ((obj->what == BULLET) || (obj->what == MISSILE)) { this_obj->shield -= obj->extra.bullet.damage; obj->shield = 0; AS_SetPic(obj->pic,EXPLODE); if (this_obj->shield<=0) AS_SetPic(this_obj->pic,EXPLODE);} if (this_obj->what == BULLET) || (this_obj->what == MISSILE)) { obj->shield -= this_obj->extra.bullet.damage; this_obj->shield = 0; AS_SetPic(this_obj->pic,EXPLODE); if (obj->shield<=0) AS_SetPic(obj->pic,EXPLODE);} } else if (obj->what <= SUPPLY)&& (obj->extra.animate.target == this_obj) { /* code to handle breeding, grabbing, etc. */ } else if (this_obj->what <= SUPPLY)&& (this_obj->extra.animate.target==obj) { /* same code with this_obj and obj reversed */ } else if (this_obj->what==STICKY)&&(obj->what==STICKY) { /* merge two sticky bricks into one object */ } else { /* objects bounce off of each other */ tempx = obj->velx * obj->mass; tempy = obj->vely * obj->mass; /* possible collision damage implementation: obj->shield -= ((this_obj->velx * this_obj->velx) + (this_obj->vely * this_obj->vely)) * this_obj->mass; this_obj->shield -= ((obj->velx * obj->velx) + (obj->vely * obj->vely)) * obj->mass; Alternate possibility: Calculate total kinetic energy as above, then recalculate after adjusting momentum, and subtract the difference from each of the colliders' shields (half each? proportional to mass?) */ obj->velx = (this_obj->velx * this_obj->mass) /obj->mass; obj->vely = (this_obj->vely * this_obj->mass) /obj->mass; this_obj->velx = tempx/this_obj->mass; this_obj->vely = tempy/this_obj->mass; } } this_obj=this_obj->next_hash; } } void UN_Shift(long sectx, long secty, object *obj) {/* update sector lists */ /* first remove us from our old list */ if (obj->next_hash != NULL) { /* if there is a next object (note that you can ** avoid this check if the final object in any list is a ** special dummy object)(you only need one such object) */ (obj->next_hash)->prev_hash = obj->prev_hash; /* set next object to know who now points at it. */ } if (obj->prev_hash != NULL) /* This is only for debugging! It *should* always be true. */ *(obj->prev_hash) = obj->next_hash; /* set the object that pointed to us to point to the object to which ** we pointed */ else { /* ERROR CONDITION */ } /* now insert us at the start of the new list */ obj->prev_hash = &(sector[sectx][secty]); /* get who points to us */ obj->next_hash = sector[sectx][secty]; /* get who we point to */ sector[sectx][secty] = &obj; /* put ourself at sector list's start */ if (obj->next_hash != NULL) (obj->next_hash)->prev_hash = &(obj->next_hash); /* set next object's prev_hash to point to our next_hash pointer */ } void UN_InsertObject(long sectx, long secty, object **obj) /* abbreviated form of UN_Shift(), used for inserting a new object into the ** objects list and its sector[][] list; assumes that nothing critical is ** being pointed to only by obj->prev_hash, obj->next_hash, obj->next_ob, or ** obj->prev_ob */ { (*obj)->next_ob=objects; if (objects!=NULL) /* should always be true, used for debugging */ objects->prev_ob=obj; else /* ERROR */ ; objects=(*obj); (*obj)->prev_hash = &(sector[sectx][secty]); (*obj)->next_hash = sector[sectx][secty]; sector[sectx][secty] = *obj; if ((*obj)->next_hash != NULL) ((*obj)->next_hash)->prev_hash = &((*obj)->next_hash); } object *UN_CreateObject() { /* Returns an object (for alife creation, UN_InitTable(), or whenever else ** we need an object). Note that nothing can be assumed about the initial ** values of any of the objects' variables, especially next_ob and prev_ob. */ if (spares==NULL) return (object *)malloc(sizeof(object)); else { object *tob=spares; spares=spares->next_ob; return tob; } } void UN_DeleteObject(object *obj) { /* Removes an object in the objects list from that list and its sector[][] ** list. */ if (obj->next_ob!=NULL) (obj->next_ob)->prev_ob=obj->prev_ob; *(obj->prev_ob)=obj->next_ob; if (obj->next_hash!=NULL) (obj->next_hash)->prev_hash=obj->prev_hash; *(obj->prev_hash)=obj->next_hash; obj->next_ob=spares; spares->prev_ob= &(obj->next_ob); spares=obj;} void UN_InitTable() { int i; /* initialize starting objects (as in, we *know* that we'll need at least ** STARTOBJECTS objects, so let's allocate them while the user expects ** initialization lag) */ spares=NULL; objects=(object *)malloc(sizeof(object)); objects->next_ob=NULL; for (i=1;inext_ob=objects; objects->prev_ob= &(tobj->next_ob); objects=tobj; } objects->prev_ob= &objects; /* This leaves undefined objects in the objects list, but UN_InitGame will ** take care of that. */ /* now to initialize sin[] and cos[] lookup tables */ for (i=0;i<255;i++) { sin[i]=sin(i*360/256); cos[i]=cos(i*360/256); } } /* does anyone have a better way of doing this? Maybe UN_sin[] and UN_cos[] ** to avoid confusion with the 360 degree sin() and cos() ? */ void UN_ReSeed() { /* TO BE CREATED */ /* will have to adjust to make sure that not too many objects are in play at ** once...may even remove isolated inanimate objects (or might not?) */ } void UN_InitSector() { /* TO BE CREATED */ /* needs: UN_ReSeed() */ } char UN_NewSector() { /* TO BE CREATED */ /* calls UN_InitSector() or returns to the current sector after a mid-game ** break, depending on the player's progress...this is where most of the ** between-action stuff will be */ } void UN_InitGame() { /* TO BE CREATED */ /* needs: UN_InitSector() */ } void UN_NewLife() { /* TO BE CREATED */ /* sets user to point to a non-dead PLAYER object */ } char UN_PlayGame() { /* Will be called when a sector has been started, either after UN_InitGame() or by a game having been paused in mid sector, then unpaused */ long lasticks=FE_Set(); /* ticksper is set by FE_InitSystem, maybe it should be set by FE_Set() ** and reset by FE_Update(), like lasticks? */ while (1) { probes_exist=0; for (curobj=objects;curobj!=NULL;) { tobj=curobj->next; if (curobj->shield<=0) UN_DeleteObject(curobj); curobj=tobj; } for (curobj=objects;curobj!=NULL;curobj=curobj->next_ob) { if (curobj->shield>0) UN_UpdateObject(curobj); if (user->shield<=0) { AS_PlayFX(FX_DIE); if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } /* UN_NewLife() returns 1 if no lives left for the player */ if ((lasticks=FE_GetTicks(lasticks))>0) AI_DoQueue(lasticks); /* kludge to avoid calling FE_GetTicks twice per update */ lasticks=FE_Update(user); /* syskeys that aren't handled below handled here */ if ((SYSKEYS)&4) FE_ToggleSound(); if ((SYSKEYS)&2) return 2; if ((SYSKEYS)&1) return MA_ConfirmQuit(2); if (!(probes_exist)) if (UN_NewSector()) return 1; /* we will probably want to change these conditions */ /* this would also be an ideal place to put a possible call to UN_ReSeed() if there are too few objects */ }} /* Return codes for UN_PlayGame: 0 = quitting, 1 = game over, 2 = paused */ From compuserve.com!71044.2164 Wed Jun 28 10:28:35 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sR0ue-000fJ3C; Wed, 28 Jun 95 10:28 PDT Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id NAA06319; Wed, 28 Jun 1995 13:26:15 -0400 Date: 28 Jun 95 13:25:01 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Universe Cc: AG-Directors Subject: universe.h 0.42 Message-ID: <950628172501_71044.2164_GHI93-3@CompuServe.COM> /* Universe header version 0.42, copyright us 6/27/1995 */ /* defines for object->what note that all animate objects are <= MISSILE (assuming BULLET exhibits no behaviour, just goes on momentum) */ #define PLAYER 0 #define PROBE 1 #define SUPPLY 2 #define MISSILE 3 #define BULLET 4 #define ASTEROID 5 #define UF_EGG 6 #define F_EGG 7 #define D_EGG 8 #define D_PLAYER 9 #define D_PROBE 10 #define D_SUPPLY 11 #define UNMOVABLE 12 #define SPECIAL 13 #define STICKY 14 /* more #defines */ #define SUBSIZE 33554432 #define SUBPOWER 25 /* SUBPOWER = log(base2) (SUBSIZE) */ /* intended use: floor(z / SUBSIZE) == z >> SUBPOWER; the second is faster */ #define NUMSUBS 64 #define STARTOBJECTS 100 /* This is the number of objects that we allocate at boot-up. */ /* Maybe this should be set by configuration? This would necessitate ** something (probably FE) being run before UN_InitTable(), though. */ #define MAX_X SUBSIZE*NUMSUBS #define MAX_Y SUBSIZE*NUMSUBS #define MAX_BBSIDE SUBSIZE /* standard object definition */ /* Explanation of structure: typedef struct ob { long x, y: location of object (needs to be signed: the code assumes that the values can be < 0, and the code won't work otherwise...in this case because of the torrodial space implementation) long velx, vely: movement vector (needs to be signed) picture *pic: picture for FE and AS unsigned long what: what the object is: PLAYER - player PROBE - probe ASTEROID - asteroid BULLET - bullet (aka: brain-dead missile) MISSILE - missile (aka: homing bullet) UF_EGG - unfertilized egg F_EGG - fertilized egg D_EGG - dead egg D_PLAYER - dead player D_PROBE - dead probe SUPPLY - supply ship D_SUPPLY - dead supply ship UNMOVABLE - unmovable object SPECIAL - special object STICKY - sticky brick; just like asteroid except that two sticky bricks stick together on collision long facdir: facing direction 0...255 (needs to be signed) PLAYER PROBE SUPPLY BULLET MISSILE: for navigation PLAYER PROBE SUPPLY?: for firing every object: for animations, for example a collision objects may perhaps turn - or perhaps not unsigned long mass: mass of object NOTE: mass should *never* be zero!! (and mass shouldn't be too low either) PLAYER PROBE SUPPLY BULLET MISSILE: thrust needs this every object: collision needs this unsigned long bboxside: length of side of bounding box every object: collision needs this long shield: currently remaining shield of object (needs to be signed) every object: if shield <= zero then the object dies What happens upon death: PLAYER -> D_PLAYER PROBE -> D_PROBE ASTEROID -> breaks into smaller asteroids or vanishes BULLET -> explodes, then vanishes MISSILE -> explodes, then vanishes UF_EGG -> D_EGG F_EGG -> D_EGG D_EGG -> vanishes D_PLAYER -> vanishes D_PROBE -> vanishes SUPPLY -> D_SUPPLY D_SUPPLY -> vanishes UNMOVABLE -> vanishes (or may be indestructable?) SPECIAL -> depends on what we do with this STICKY -> breaks into smaller sticky bricks or vanishes long energy: currently remaining energy of object (needs to be signed) can be used for navigation/firing by animate objects, and is used to denote nutricious value for inanimate objects PLAYER PROBE MISSILE SUPPLY: used for thrust PLAYER PROBE SUPPLY(?): for firing weapons PLAYER PROBE: to lay an egg, and to fertilize an egg UF_EGG: energy may decay slowly; also nutricious value F_EGG: energy is invested in properties; also nutricious value D_PLAYER D_PROBE D_SUPPLY D_EGG ASTEROID STICKY UNMOVABLE: nutricious value unsigned long age: Frames since creation or last "what" change - probes may use age to base actions on - eggs can hatch at a certain time after fertilisation - certain weapons may explode after a certain time - nutricious value (energy) of dead objects may degenerate with age - statistical purposes Now for the shared memory with extra non generic object information: union { struct { ob *target: current target of object long thrust: thrust power of object long turn: turn speed of object genotype *gtype: pointer to genotype of object - alife stuff weapon *wlist: pointer to the current weapon in the weapon list of this object - system needs to be refined later, but whatever this points to will be fired if the object fires action actions: virtual keypresses done by this probe } animate; (used by PLAYER, PROBE, and SUPPLY) struct { long damage: explosive force of object long type: type of explosion (only contact-damage is supported right now) } bullet; (used by BULLET and MISSILE) (perhaps another struct for 'special' stuff, like food and eggs) } extra; ob *next_hash: pointer to next object in list ob **prev_hash: pointer to pointer at this object, **(ob->prev_hash)=ob if (ob!=first object on its sector list) *(ob->prev_hash)= previous_ob->next_hash else *(ob->prev_hash)= sector[ob->x >> SUBSIZE][ob->y >> SUBSIZE] If you're confused by this, UN_Shift() should clear up the way object->prev_hash, object->next_hash, objects, and sector[][] are used. Note that this is only for objects in the objects list. There may be other objects that are on completely seperate lists (weapon lists, for instance?) ob *next_ob, **prev_ob: Used for objects and spares linked lists in a similar manner as next_hash and prev_hash; see UN_DeleteObject() for details on this and spares. Note that we may want to get rid of prev_ob; I just included it for continuity with next_hash and prev_hash. } object; */ /* Condensed: */ typedef struct ob { long x, y; long velx, vely; picture *pic; long facdir, shield, energy; unsigned long what, mass, bboxside, age; union { struct { ob *target; long thrust,turn; genotype *gtype; weapon *wlist; action actions; } animate; struct { long damage, type; } bullet; } extra; ob *next_hash, **prev_hash, *next_ob, **prev_ob; } object; object *objects, *spares; object *sector[NUMSUB][NUMSUB]; /* objects points to the start of the linked list containing all objects ** in play, sector contains the subsector lists, spares points to a linked ** list containing all of the spaces allocated to objects but not currently ** being used */ object *user; /* pointer to current player's probe */ char curwhat; /* current what the object is */ long probes_exist; /* probes still exist */ long curthrust; /* current thrust */ long tempx, tempy; /* temporary subsector holders */ long subx, suby; /* more temporary subsector holders */ float sin[256],cos[256]; /* precomputed sin and cos lookup tables */ object *curobj; /* pointer to object currently being checked */ object *tobj; /* a temporary object pointer holder */ long curpic; /* current picture number for object */ long xh,txh,ttxh,dx,yh,tyh,ttyh,dy; /* variables for collision detection */ /* current picture number = ** facing (0-255) + THRUSTPIC + BRAKEPIC + TARGETPIC */ #define THRUSTPIC 256 #define BRAKEPIC 512 #define TARGETPIC 1024 #define SYSKEYS user->extra.animate.actions /* user always points to the current player's ship, and system keys will always be passed to the universe (as opposed to main/menu) part of the game by that object's actions */ /* function prototypes */ action FE_GetKeys(); action AI_GetKeys(object *obj); void AI_Interrupt(object *obj, long type); /* need #define for THRUST_FAIL and BRAKE_FAIL types */ void AS_SetPic(picture *pic,long type); /* handles animation */ long thrustcost[MAX_LONG_INT]; /* lookup for thrustcost */ long FE_Set(); void AS_PlayFX(long type); void AS_ShowMovie(long number); long FE_GetTicks(long lastset); void AI_DoQueue(long fegetticks); long FE_Update(object *obj); void FE_ToggleSound(); void UN_CheckObject (object *obj); void UN_Shift(long sectx, long secty, object *obj); void UN_InsertObject(long sectx, long secty, object **obj); object *UN_CreateObject(); void UN_DeleteObject(object *obj); void UN_InitTable(); void UN_ReSeed(?); void UN_InitSector(?); char UN_NewSector(); void UN_InitGame(); void UN_NewLife(); char UN_PlayGame(); From compuserve.com!71044.2164 Wed Jun 28 10:31:57 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-3.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sR0xu-000fJ5C; Wed, 28 Jun 95 10:31 PDT Received: by arl-img-3.compuserve.com (8.6.10/5.950515) id NAA21304; Wed, 28 Jun 1995 13:29:46 -0400 Date: 28 Jun 95 13:27:09 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Universe Cc: AG-Directors Subject: main.c 0.42 Message-ID: <950628172708_71044.2164_GHI93-4@CompuServe.COM> /***************************************************************************\ * Alife Game - main.c code file * *---------------------------------------------------------------------------* * Copyright (C) 1995 Us. All Rights Reserved. * *---------------------------------------------------------------------------* * Created by: Adrian Tymes * * Last Revised: June, 1995 * * By: Adrian Tymes * * Version #: 0.42 * \***************************************************************************/ #include "universe.c" #include "alife.c" #include "fe.c" #include "as.c" #define NEW_ULX 200 #define NEW_ULY 150 #define NEW_LRX 407 #define NEW_LRY 305 /* "New Game" button boundaries on 0-1023,0-767 screen */ #define LOAD_ULX 616 #define LOAD_ULY 150 #define LOAD_LRX 823 #define LOAD_LRY 305 /* "Load Game" button boundaries on 0-1023,0-767 screen */ #define SAVE_ULX 616 #define SAVE_ULY 306 #define SAVE_LRX 823 #define SAVE_LRY 461 /* "Save Game" button boundaries on 0-1023,0-767 screen */ /* this button is disabled unless the game is paused */ #define CONT_ULX 200 #define CONT_ULY 306 #define CONT_LRX 407 #define CONT_LRY 461 /* "Continue Game" button boundaries on 0-1023,0-767 screen */ /* this button is disabled unless the game is paused */ #define REP_ULX 408 #define REP_ULY 150 #define REP_LRX 615 #define REP_LRY 305 /* "Replay Movie" button boundaries on 0-1023,0-767 screen */ /* this button becomes "Show Background Story" when game is not paused */ #define INST_ULX 408 #define INST_ULY 306 #define INST_LRX 615 #define INST_LRY 461 /* "Instructions" button boundaries on 0-1023,0-767 screen */ #define OPT_ULX 200 #define OPT_ULY 462 #define OPT_LRX 407 #define OPT_LRY 617 /* "Options" button boundaries on 0-1023,0-767 screen */ #define CRED_ULX 408 #define CRED_ULY 462 #define CRED_LRX 615 #define CRED_LRY 617 /* "Credits" button boundaries on 0-1023,0-767 screen */ #define QUIT_ULX 616 #define QUIT_ULY 462 #define QUIT_LRX 823 #define QUIT_LRY 617 /* "Quit" button boundaries on 0-1023,0-767 screen */ #define UN_Within(x,y,a,b,c,d) ((x>a)&&(xb)&&(y Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sR26u-000fJ2C; Wed, 28 Jun 95 11:45 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56884-2>; Wed, 28 Jun 1995 14:42:57 -0400 Date: Wed, 28 Jun 1995 14:42:51 -0400 From: Jeff Lait cc: AG-Universe , AG-Directors To: AG-Universe , AG-Directors Subject: Re: universe.c 0.42 In-Reply-To: <950628172318_71044.2164_GHI93-2@CompuServe.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks... I'll get back to you ASAP re: POC IV's combatibility with all this :> - Jeff Lait (SOL) From post.demon.co.uk!darkin.demon.co.uk!Christian Tue Jul 11 12:35:21 1995 Return-Path: <@post.demon.co.uk:Christian@darkin.demon.co.uk> Received: from disperse.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sVl5H-000fJ2C; Tue, 11 Jul 95 12:35 PDT Received: from post.demon.co.uk by disperse.demon.co.uk id aa18451; 11 Jul 95 18:23 +0100 Received: from darkin.demon.co.uk by post.demon.co.uk id aa00592; 11 Jul 95 18:23 +0100 Date: Tue, 11 Jul 1995 07:42:32 GMT From: Christian Darkin Reply-To: Christian@darkin.demon.co.uk Message-Id: <224@darkin.demon.co.uk> To: ag-directors@alnilam.krl.caltech.edu Subject: Trawl for new programmers X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 17 Hi, Are we ready to put out the call for programmers on some of the newsgroups? I did the edits people suggested to the proposed post, but I`m not sure at what point we actually want the new people. If we want to put it out now, can somebody send me the list we talked about. My copy got deleted. Thanks! -- Christian Darkin From compuserve.com!71044.2164 Tue Jul 11 17:20:45 1995 Return-Path: <71044.2164@compuserve.com> Received: from dub-img-3.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sVp8a-000fJ2C; Tue, 11 Jul 95 16:54 PDT Received: by dub-img-3.compuserve.com (8.6.10/5.950515) id TAA03749; Tue, 11 Jul 1995 19:46:17 -0400 Date: 11 Jul 95 19:42:13 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Directors Subject: Re: Trawl for new programmers Message-ID: <950711234212_71044.2164_GHI128-1@CompuServe.COM> The universe group is ready for new programmers now. I did not keep the list of newsgroups, though. From dl.ac.uk!mbbad Wed Jul 12 02:32:59 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sVyA4-000fJ3C; Wed, 12 Jul 95 02:32 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id KAA10656 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Wed, 12 Jul 1995 10:29:35 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@alnilam.krl.caltech.edu id AA17943; Wed, 12 Jul 95 10:29:28 +0100 Date: Wed, 12 Jul 1995 10:29:28 +0100 (BST) From: "I. Badcoe" Subject: Re: Trawl for new programmers Cc: ag-directors@alnilam.krl.caltech.edu In-Reply-To: <224@darkin.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 11 Jul 1995, Christian Darkin wrote: > Hi, > Are we ready to put out the call for programmers on some of the newsgroups? I > did the edits people suggested to the proposed post, but I`m not sure at what > point we actually want the new people. Except that AG-alife is mostly asleep at the moment so it's probably not the best time to introduce new people. Badders From charles Tue Jul 18 12:49:30 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sYIe0-000fJ3C; Tue, 18 Jul 95 12:49 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA26632; Tue, 18 Jul 1995 12:47:23 -0700 Message-Id: <9507181947.AA26632@altair.krl.caltech.edu> Subject: *sigh* back on line at last... To: ag-directors Date: Tue, 18 Jul 1995 12:47:23 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 885 Greetings folks. Well, I've been on vacation for a bit over a week now; I didn't mention this to the list sooner because I expected to have full access while I'm here, but as it turned out, my parents are having trouble with their phone lines - just an occasional burst of static every five minutes or so, but just enough to make trying to use the modem completely pointless. Not that I'm on I just scaned through the *487* new messages I found in my mailbox. I replied to any that immediately looked urgent, but admitedly I did not read them all. If there was anything important that as sent to me, please point it out so that I know to take a better look at it. I'll go through things as I can. I will start being on again steadily now. It looks like a lot is happening - that's great! I'll make some more comments as I have a chance to go through it all. --- Charles From phil.ruu.nl!faassen Tue Jul 18 16:01:23 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sYLdf-000fJ3C; Tue, 18 Jul 95 16:01 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.6.12/8.6.12) with ESMTP id AAA14595; Wed, 19 Jul 1995 00:57:48 +0200 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.12/8.6.12) id AAA02574; Wed, 19 Jul 1995 00:57:47 +0200 From: Martijn Faassen Message-Id: <199507182257.AAA02574@laurel.stud.phil.ruu.nl> Subject: Prolonged absence :( To: ag-alife@alnilam.krl.caltech.edu (ag alife), ag-universe@alnilam.krl.caltech.edu (ag universe), ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Wed, 19 Jul 1995 00:57:46 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1233 Hello everybody, I know I haven't been around much recently (though I've been keeping up with the mails). I've been busy with classes and finals, and this week and last week with a programming project for a class. (it's a GP-like system, though only for simple binary decision trees, in C, so let's say I'm doing 'research' for project Von Neumann. :) Next week, tuesday the 25th, I'll be leaving for a month long holiday in the states. If there's anybody on this list in the deep south, please let me know asap (I'll be in Texas and Alabama, visiting friends I know on the net, mainly). I won't be able to check my home account after the 25th. I will probably be able to get on the net to read the archives, and perhaps to mail off something from someone else's account, as well. Also, if I find any free time, I'll work on this project with pencil and paper, probably mainly some C code for the alife engine. I'm sorry I can't work on the Universe code so much, I half hope there's still work to do in the end of august, when I get back (the other half of the hope is of course seeing a working universe/FE program). So, you all probably will hear from me soon, but not so much. But, I'll be back more fully later. Martijn From firga.sun.ac.za!9515291 Tue Jul 25 07:50:13 1995 Return-Path: <9515291@firga.sun.ac.za> Received: from oliver.sun.ac.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0salHv-000fJ2C; Tue, 25 Jul 95 07:48 PDT Received: from styx.sun.ac.za by oliver.sun.ac.za with smtp (Smail3.1.29.0 #2) id m0sakd2-001590C; Tue, 25 Jul 95 16:06 EET Received: From SUN_FIRGA/WORKQUEUE by styx.sun.ac.za via Charon-4.0A-VROOM with IPX id 100.950725155959.320; 25 Jul 95 16:06:41 -0200 Message-ID: From: "G-J van Rooyen" <9515291@firga.sun.ac.za> Organization: University of Stellenbosch To: ag-directors@krl.caltech.edu Date: Tue, 25 Jul 1995 15:59:54 GMT+200 Subject: Have to leave - sorry! Priority: normal X-mailer: Pegasus Mail v3.22 I'm afraid that my workload this year has caused me to be mostly absent from any discussions of game ideas and concepts. Unfortunately, I don't think that the rest of my year will be any easier, so I regret that I have to say, best of luck with the development of the game, I hope I've been some help in the earlier development stages, but I'll be getting off the boat from here. Please remove my name from the group mailing lists (ag-directors, ag-art- sound and ag-pcx). Nevertheless, I'll be watching the web page and public ftp site with interest, and if I find the chance to join again, I'll drop you a note. Cheers G-J +-------------------------------------------------+ | 9515291@firga.sun.ac.za (Gert-Jan van Rooyen) | | University of Stellenbosch | | South Africa | +-------------------------------------------------+ From charles Tue Aug 8 07:50:25 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sfpz4-000fJ2C; Tue, 8 Aug 95 07:50 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA05331; Tue, 8 Aug 1995 07:48:58 -0700 Message-Id: <9508081448.AA05331@altair.krl.caltech.edu> Subject: Quick Preview of Status Report... To: ag-directors Date: Tue, 8 Aug 1995 07:48:58 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2996 Hi guys; I'm about to send this to ag-general and thought I'd give you a quick chance to go over it first. I don't think there is anything too importent in it. I'm planning on getting it out by this afternoon (around 1PM PST) so get your comments in by then if you have any. ------------------------------------- Greetings folks! Do to the distict lack of activity for the summer, I thought it would be appropriate to post a general status report of the project as a whole. First of all, I'd like to welcome the 12 new people into the project who have just joined in the past several days. Admitedly this was the result of a mistaken post to comp.ai.games, but we're glad to have the new blood none the less. It is interesting to note that a post in the middle of a thread of such a relatively low volume news group did come up with so many responces. I think we should certainly wait a while before we do a major recruiting now; at least until the new folks are adjusted to the project. Anyway, I think the brunt of this message is going to be dedicated to those of you just joining. Things have been quiet for the summer thus far, and I don't really expect things to pick up until the fall. I know a number of people are currently away (either from school, on vacation, or just with other work to do). I myself am frantically preparing for my PhD candidacy exam, so I'm going to be relatively low volume until Sept. 28th at ~3PM :-). On the mailing lists: Hopefully all of you know which mailing lists you are on (I think I was clear about where I was adding you). In order to send mail to the list, just send it to @krl.caltech.edu. Please note that automatically replying to the list is *not* set up as default; if you just hit 'reply' on a letter from the list it will go only to the person who sent it. This typically leaves you with the options of either hitting 'group-reply' or else manually typing the mailing-list name over again. Also, there is one new mailing list which was not mentioned on the web pages; this is ag-fe. This is not a group you can sign up explicitly to. It instead bounces all the messages which come to it to the other Front End groups (ag-pcx, ag-mac, and ag-amiga) and to the ag-universe group. As expected, this group is for the discussion of the general structure of the front-ends. Finally on this topic of mailing lists, Stuart McDonald is very interested in starting up an ag-unix group for making an X front end to the game. I think this is something that we really need, and am wondering how many people would be interested in joining said group if it were created. I think that's about it for the moment. The only other thing I want to mention to our initiates is that you guys shouldn't worry much about contributing immidiately; feel free to lurk all you like. If you have something to say, by all means say it, but just don't feel pressured to start contributing immediately... Good luck to all! --- Charles From charles Wed Aug 9 22:14:55 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sgPxE-000fJ5C; Wed, 9 Aug 95 22:14 PDT Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/14Apr95-0417PM) id AA18290; Wed, 9 Aug 1995 22:13:23 -0700 Message-Id: <9508100513.AA18290@altair.krl.caltech.edu> Subject: An interesting note... To: ag-directors Date: Wed, 9 Aug 1995 22:13:23 -0800 (PDT) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 564 The Project: Von Neumann home page has been hit 109 times in the past 9 days! Eeeek. Just imagine if we ever do advertise for real! Also, does anyone have any objects to me creating the ag-unix group? I got a couple of other people interested in joining it. One has a lot of experience with X programing of this kind, and the another (the one who offered to direct the group) works for HP and has also done a decent amount of work with X. Sounding good to me... :-) --- Charles PS: Whose around now anyway? Jeff and Christian I know... anyone else? From undergrad.math.uwaterloo.ca!jmlait Thu Aug 10 08:53:58 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sgZve-000fJ3C; Thu, 10 Aug 95 08:53 PDT Received: from descartes.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56862-1>; Thu, 10 Aug 1995 11:50:26 -0400 Date: Thu, 10 Aug 1995 11:50:07 -0400 From: Jeff Lait cc: ag-directors@krl.caltech.edu To: ag-directors@krl.caltech.edu Subject: Re: An interesting note... In-Reply-To: <9508100513.AA18290@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 10 Aug 1995, Splinterwood wrote: > The Project: Von Neumann home page has been hit 109 times in the past 9 > days! Eeeek. Just imagine if we ever do advertise for real! > > Also, does anyone have any objects to me creating the ag-unix group? I > got a couple of other people interested in joining it. One has a lot of > experience with X programing of this kind, and the another (the one who > offered to direct the group) works for HP and has also done a decent > amount of work with X. Sounding good to me... :-) > No objections here. (Though why I'd object to such a thing, I don't know.) > --- Charles > > PS: Whose around now anyway? Jeff and Christian I know... anyone else? Though not for much longer. On the 11th I'm off from Waterloo, and will be in touch sparingly until I get to Ottawa around the 28th. But around then I should be back in touch (Touch wood.) - Jeff Lait (SOL) From hsmpk14a-103.Eng.Sun.COM!gtaylor Thu Aug 10 10:08:40 1995 Return-Path: Received: from mercury.Sun.COM by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0sgb5x-000fJ5C; Thu, 10 Aug 95 10:08 PDT Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id KAA15958; Thu, 10 Aug 1995 10:05:07 -0700 Received: from hape.eng.sun.com (hape-103.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13940; Thu, 10 Aug 1995 10:04:50 -0700 Received: from zaphod.eng.sun.com by hape.eng.sun.com (5.x/SMI-SVR4) id AA12390; Thu, 10 Aug 1995 10:04:48 -0700 Received: by zaphod.eng.sun.com (5.x/SMI-SVR4) id AA25281; Thu, 10 Aug 1995 10:05:00 -0700 Date: Thu, 10 Aug 1995 10:05:00 -0700 From: gtaylor@hsmpk14a-103.Eng.Sun.COM (Greg Taylor) Message-Id: <9508101705.AA25281@zaphod.eng.sun.com> To: ag-directors@krl.caltech.edu Subject: Re: An interesting note... X-Sun-Charset: US-ASCII > The Project: Von Neumann home page has been hit 109 times in the past 9 > days! Eeeek. Just imagine if we ever do advertise for real! > Wowie, that's a lot of WWW surfers, just dropping by. I think we'll get a lot of attention at the start of the new school year, when we start advertising like mad! > Also, does anyone have any objects to me creating the ag-unix group? I Nope, feel free. In fact, I think some of the big Suns, HPs, and SGI machines would be the best things to do this game justice :) > got a couple of other people interested in joining it. One has a lot of > experience with X programing of this kind, and the another (the one who > offered to direct the group) works for HP and has also done a decent > amount of work with X. Sounding good to me... :-) > :) Sounds grand. > --- Charles > > PS: Whose around now anyway? Jeff and Christian I know... anyone else? I'm psuedo-around. Work is a lot of...well...work, and I don't feel like having anything to do with computers when I'm off work. I'll be a bit more active come the start of the Cal Poly school year... -=GT=- From compuserve.com!71044.2164 Sat Aug 12 10:08:47 1995 Return-Path: <71044.2164@compuserve.com> Received: from dub-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0shK34-000fJ2C; Sat, 12 Aug 95 10:08 PDT Received: by dub-img-4.compuserve.com (8.6.10/5.950515) id NAA05439; Sat, 12 Aug 1995 13:05:12 -0400 Date: 12 Aug 95 13:02:43 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Directors Subject: Re: An interesting note... Message-ID: <950812170243_71044.2164_GHI25-1@CompuServe.COM> > The Project: Von Neumann home page has been hit 109 times in the past 9 > days! Eeeek. Just imagine if we ever do advertise for real! Note that some of that might be prospective newcomers, or some of our old members who can't access their college e-mail accounts, checking the mailing lists instead of subscribing to them (that's what I did for a while, so others might...) > Also, does anyone have any objects to me creating the ag-unix group? I > got a couple of other people interested in joining it. One has a lot of > experience with X programing of this kind, and the another (the one who > offered to direct the group) works for HP and has also done a decent > amount of work with X. Sounding good to me... :-) No problems here. > PS: Whose around now anyway? Jeff and Christian I know... anyone else? I'll be around all summer. And next summer, if this project lasts that long. From compuserve.com!71044.2164 Thu Oct 5 11:32:18 1995 Return-Path: <71044.2164@compuserve.com> Received: from dub-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t0v5U-000fJzC; Thu, 5 Oct 95 11:32 PDT Received: by dub-img-5.compuserve.com (8.6.10/5.950515) id OAA16762; Thu, 5 Oct 1995 14:27:35 -0400 Date: 05 Oct 95 14:25:01 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Universe Cc: AG-Directors Subject: UN_ and MA_ code 0.51 Message-ID: <951005182500_71044.2164_GHI81-1@CompuServe.COM> Badcoe's changes: (i) Took movement code out of UN_CheckObject and put it in UN_Movement. (ii) Took Animate-Object code out of UN_CheckObject and put it in UN_Animate. (iii) Filled in UN_NewSector (or a similar name). (iv) Added dummy objects to the ends of all lists. (v) Altered end of list detection to look for dummy objects. (vi) Changed some names to make the code easier to read. (vii) Added a lot of comments tagged , these are all *important* (down ego). (viii) Moved huge comments to after functions and tagged them as <<=A3>> (=A3 is a number) in the code. (viiii) Changed list accesses to go through the dummy objects and not through pointers (we may as well use them). (ix) Put list accesses into separate routines (most of, at least). (x) Ran the whole thing through indent to make a consistent style (but I did that before coding so I'll have broken the style myself (DUH!)). My changes: a: Tagged some of my comments to differentiate my changes from Badcoe's. b: Filled in UN_NewLife(), UN_NewSector(), and UN_InitGame(). c: Created stubs for the missing MA_ functions, and filled in the MA_ConfirmQuit() stub. d: Removed noise characters (and hopefully no important characters), then re-checked the indentation. e: Added prototypes for the functions Badcoe added. **ULTRA IMPORTANT NOTE FOR ANYONE ADDING UN_ FUNCTIONS OR CALLS TO OTHER FUNCTIONS TO THE UNIVERSE CODE: DO *NOT* FORGET TO ADD A PROTOTYPE TO THE UNIVERSE.H SECTION! Even if it is only for internal use, it helps a *lot* when tracking down what functions we have. And the other groups have to know which of their functions we call! I think that the code below is (finally) compilable, given the appropriate routines from the other groups. Would somebody with the appropriate function stubs and #defines please see if it can compile? This is main.c CUT_HERE_CUT_HERE /***************************************************************************\ * Alife Game - main.c code file * *---------------------------------------------------------------------------* * Copyright (C) 1995 Us. All Rights Reserved. * *---------------------------------------------------------------------------* * Created by: Adrian Tymes * * Last Revised: October, 1995 * * By: Adrian Tymes * * Version #: 0.051 * \***************************************************************************/ #include "universe.h" #include "alife.h" #include "fe.h" #include "as.h" #define NEW_ULX 200 #define NEW_ULY 150 #define NEW_LRX 407 #define NEW_LRY 305 /* "New Game" button boundaries on 0-1023,0-767 screen */ #define LOAD_ULX 616 #define LOAD_ULY 150 #define LOAD_LRX 823 #define LOAD_LRY 305 /* "Load Game" button boundaries on 0-1023,0-767 screen */ #define SAVE_ULX 616 #define SAVE_ULY 306 #define SAVE_LRX 823 #define SAVE_LRY 461 /* "Save Game" button boundaries on 0-1023,0-767 screen */ /* this button is disabled unless the game is paused */ #define CONT_ULX 200 #define CONT_ULY 306 #define CONT_LRX 407 #define CONT_LRY 461 /* "Continue Game" button boundaries on 0-1023,0-767 screen */ /* this button is disabled unless the game is paused */ #define REP_ULX 408 #define REP_ULY 150 #define REP_LRX 615 #define REP_LRY 305 /* "Replay Movie" button boundaries on 0-1023,0-767 screen */ /* this button becomes "Show Background Story" when game is not paused */ #define INST_ULX 408 #define INST_ULY 306 #define INST_LRX 615 #define INST_LRY 461 /* "Instructions" button boundaries on 0-1023,0-767 screen */ #define OPT_ULX 200 #define OPT_ULY 462 #define OPT_LRX 407 #define OPT_LRY 617 /* "Options" button boundaries on 0-1023,0-767 screen */ #define CRED_ULX 408 #define CRED_ULY 462 #define CRED_LRX 615 #define CRED_LRY 617 /* "Credits" button boundaries on 0-1023,0-767 screen */ #define QUIT_ULX 616 #define QUIT_ULY 462 #define QUIT_LRX 823 #define QUIT_LRY 617 /* "Quit" button boundaries on 0-1023,0-767 screen */ #define UN_Within(x,y,a,b,c,d) ((x>a)&&(xb)&&(ywhat note that all animate UN_Objects are <= MISSILE (assuming BULLET exhibits no behaviour, just goes on momentum) */ #define PLAYER 0 #define PROBE 1 #define SUPPLY 2 #define MISSILE 3 #define BULLET 4 #define ASTEROID 5 #define UF_EGG 6 #define F_EGG 7 #define D_EGG 8 #define D_PLAYER 9 #define D_PROBE 10 #define D_SUPPLY 11 #define UNMOVABLE 12 #define SPECIAL 13 #define STICKY 14 /* more #defines */ #define SUBSIZE 67108864 #define SUBPOWER 26 /* SUBPOWER = log(base2) (SUBSIZE) */ /* intended use: floor(z / SUBSIZE) == z >> SUBPOWER; the second is faster */ #define NUMSUBS 64 #define STARTOBJECTS 100 /* This is the number of UN_Objects that we allocate at boot-up. */ /* Maybe this should be set by configuration? This would necessitate ** something (probably FE) being run before UN_InitTable(), though. */ #define MAX_X SUBSIZE*NUMSUBS #define MAX_Y SUBSIZE*NUMSUBS #define MAX_BBSIDE SUBSIZE /* standard UN_Object definition */ /* Explanation of structure: typedef struct { unsigned long x, y: location of object long velx, vely: movement vector (needs to be signed) picture *pic: picture for FE and AS unsigned long what: what the object is: PLAYER - player PROBE - probe ASTEROID - asteroid BULLET - bullet (aka: brain-dead missile) MISSILE - missile (aka: homing bullet) UF_EGG - unfertilized egg F_EGG - fertilized egg D_EGG - dead egg D_PLAYER - dead player D_PROBE - dead probe SUPPLY - supply ship D_SUPPLY - dead supply ship UNMOVABLE - unmovable object SPECIAL - special object STICKY - sticky brick; just like asteroid except that two sticky bricks stick together on collision long facdir: facing direction 0...255 (needs to be signed) PLAYER PROBE SUPPLY BULLET MISSILE: for navigation PLAYER PROBE SUPPLY?: for firing every object: for animations, for example a collision objects may perhaps turn - or perhaps not long mass: mass of object (needs to be signed for momentum computations) NOTE: mass should *never* be less than or equal to zero!! (and mass shouldn't be too low either) PLAYER PROBE SUPPLY BULLET MISSILE: thrust needs this every object: collision needs this unsigned long bboxside: length of side of bounding box every object: collision needs this long shield: currently remaining shield of object (needs to be signed) every object: if shield <= zero then the object dies What happens upon death: PLAYER -> D_PLAYER PROBE -> D_PROBE ASTEROID -> breaks into smaller asteroids or vanishes BULLET -> explodes, then vanishes MISSILE -> explodes, then vanishes UF_EGG -> D_EGG F_EGG -> D_EGG D_EGG -> vanishes D_PLAYER -> vanishes D_PROBE -> vanishes SUPPLY -> D_SUPPLY D_SUPPLY -> vanishes UNMOVABLE -> vanishes (or may be indestructable?) SPECIAL -> depends on what we do with this STICKY -> breaks into smaller sticky bricks or vanishes long energy: currently remaining energy of object (needs to be signed) can be used for navigation/firing by animate objects, and is used to denote nutricious value for inanimate objects PLAYER PROBE MISSILE SUPPLY: used for thrust PLAYER PROBE SUPPLY(?): for firing weapons PLAYER PROBE: to lay an egg, and to fertilize an egg UF_EGG: energy may decay slowly; also nutricious value F_EGG: energy is invested in properties; also nutricious value D_PLAYER D_PROBE D_SUPPLY D_EGG ASTEROID STICKY UNMOVABLE: nutricious value unsigned long age: Frames since creation or last "what" change - probes may use age to base actions on - eggs can hatch at a certain time after fertilisation - certain weapons may explode after a certain time - nutricious value (energy) of dead objects may degenerate with age - statistical purposes Now for the shared memory with extra non generic object information: union { struct { UN_Object *target: current target of object long thrust: thrust power of object long turn: turn speed of object genotype *gtype: pointer to genotype of object - alife stuff weapon *wlist: pointer to the current weapon in the weapon list of this object - system needs to be refined later, but whatever this points to will be fired if the object fires action actions: virtual keypresses done by this probe } animate; (used by PLAYER, PROBE, and SUPPLY) struct { long damage: explosive force of object long type: type of explosion (only contact-damage is supported right now) } bullet; (used by BULLET and MISSILE) (perhaps another struct for 'special' stuff, like food and eggs) } extra; UN_Object *next_hash: pointer to next object in list UN_Object **prev_hash: pointer to pointer at this object, **(ob->prev_hash)=ob if (ob!=first object on its sector list) *(ob->prev_hash)= previous_ob->next_hash else *(ob->prev_hash)= sector[ob->x >> SUBSIZE][ob->y >> SUBSIZE] If you're confused by this, UN_Shift() should clear up the way object->prev_hash, object->next_hash, objects, and sector[][] are used. Note that this is only for objects in the objects list. There may be other objects that are on completely seperate lists (weapon lists, for instance?) UN_Object *next_ob, *prev_ob: Used for objects and spares linked lists in a similar manner as next_hash and prev_hash; see UN_DeleteObject() for details on this and spares. Expanded {next,prev}_ob to be a fully linked list 'cos it's useful for target switching {and not used v.often so speed less important than for {next,prev}_hash} } UN_Object; */ /* Condensed: */ typedef struct UN_Object { unsigned long x, y; long velx, vely; picture *pic; long facdir, shield, energy, mass; unsigned long what, bboxside, age; union { struct { UN_Object *target; long thrust,turn; genotype *gtype; weapon *wlist; action actions; } animate; struct { long damage, type; } bullet; } extra; UN_Object *next_hash, **prev_hash UN_Object *next_ob, *prev_ob; }; UN_Object *Live_Objects, *Spare_Objects, *Player_Objects; UN_Object *Sectors[NUMSUBS][NUMSUBS]; /* Live_Objects points to the start of the linked list containing all ** UN_Objects in play, Sectors contains the subsector lists, Spare_Objects ** points to a list containing all allocated UN_Objects not currently being ** used */ UN_Object *User; /* pointer to current player's probe */ char curwhat; /* current what the object is */ long probes_exist; /* probes still exist */ long curthrust; /* current thrust */ long tempx, tempy; /* temporary subsector holders */ long subx, suby; /* more temporary subsector holders */ float UN_Sin[256], UN_Cos[256]; /* precomputed sin and cos lookup tables */ UN_Object *curobj; /* pointer to UN_Object currently being checked */ UN_Object *tobj; /* a temporary UN_Object pointer holder */ long curpic; /* current picture number for UN_Object */ long xh,txh,ttxh,dx,yh,tyh,ttyh,dy; /* variables for collision detection */ long StartAsteroids,StartFood,StartProbes; /* how many objects of each type to create at the beginning of the game */ UN_Object Dummies[NUMSUBS][NUMSUBS]; UN_Object Live_Dummy; UN_Object Spare_Dummy; UN_Object Player_Dummy; /* dummy objects - do not alter these outside the UN_ routines */ /* ** current picture number = facing (0-255) + THRUSTPIC + BRAKEPIC + TARGETPIC */ #define THRUSTPIC 256 #define BRAKEPIC 512 #define TARGETPIC 1024 /* ** I'm sure we can't afford 1024 pictures per UN_Object (type) ? ** ** Amd we won't: 256 pictures (maximum) for each of the facing directions, ** with the appropriate "thrusting" picture overlaid if (picture number)&256, ** similar for braking and targetting; especially targetting since that would ** only necessitate placing a non-facing-specific crosshair (or similar) on ** top of the sprite. In addition, similar types of objects would share ** their pictures (for instance, all of one type of asteroid, all of one ** species of probe, etc.). And if we can't afford 256 pictures per object ** type, then use the same picture for multiple facings: if we only want 16 ** pictures per object type, facings 0-15 would share the same picture, as ** would facings 16-31, and so on. Also, note that braking and thrusting ** will never be displayed at the same time, since the universe code won't ** allow an object to thrust and brake simultaneously. */ #define SYSKEYS User->extra.animate.actions /* User always points to the current player's ship, and system keys will always be passed to the universe (as opposed to main/menu) part of the game by that object's actions */ /* function prototypes */ action FE_GetKeys(); action AI_GetKeys(UN_Object *obj); void AI_Interrupt(UN_Object *obj, long type); /* need #define for THRUST_FAIL and BRAKE_FAIL types */ void AS_SetPic(picture *pic,long type); /* handles animation */ long thrustcost[MAX_LONG_INT]; /* lookup for thrustcost */ long FE_Set(); void AS_PlayFX(long type); void AS_ShowMovie(long number); long FE_GetTicks(long NextUpdate); void AI_DoQueue(long FETicksLeft); long FE_Update(UN_Object **SubsectorList, long CenterSubsectorX, long CenterSubsectorY); void FE_ToggleSound(); short MA_ConfirmQuit(short mode); void AL_InitPlayerGenome(UN_Object *player); void AL_InitAsteroidGenome(UN_Object *rock); void AL_InitProbeGenome(UN_Object *thing); void UN_CheckObject(UN_Object *obj); void UN_Shift(long sectx, long secty, UN_Object *obj); void UN_InsertObject(long sectx, long secty, UN_Object **obj); UN_Object *UN_CreateObject(); void UN_DeleteObject(UN_Object *obj); void UN_InitTable(); void UN_ReSeed(); void UN_InitSector(); char UN_NewSector(); void UN_InitGame(); void UN_NewLife(); char UN_PlayGame(); void UN_ObInsert(UN_Object *ob, UN_Object *dummy); void UN_ObRemove(UN_Object *ob); void UN_HashInsert(UN_Object *ob, UN_Object **list); void UN_HashRemove(UN_Object *ob); void UN_Animate(UN_Object *obj); void UN_Movement(UN_Object *obj); void UN_CreatePlayer(int x, int y); void UN_CreateAsteroid(); void UN_CreateFood(); void UN_CreateProbe(); int UN_Collision(UN_Object *which); CUT_HERE_CUT_HERE This is universe.c CUT_HERE_CUT_HERE /* Universe code version 0.51, copyright us 10/5/1995 */ #include "universe.h" /* ** Renamed (more meaningfull and also Capitalized for important arrays): ** objects -> Live_Objects ** spares -> Spare_Objects ** sector -> Sectors ** thrustcost ->ThrustCost ** ** *_Objects are all gone now (Sic Transit Gloria Mundi) instead we ** now do all list access *through* the dummy object, e.g. ** Live_Dummy.next_ob is the first live object. ** We could have MACRO's defined for these but do we really need ** them ? */ /* ** Inserts an UN_Object into the specified object list (which ** means Live_Objects, Spare_Objects or Player_Objects at the moment). ** ** Now that this is doubly linked and we have dummies, we no longer need ** pointers to the lists and can access them through the dummies ** themselves . ** ** Assumes that the UN_Object was correctly removed from any ** previous list it belonged to. */ void UN_ObInsert(UN_Object *ob, UN_Object *dummy) { ob->prev_ob = dummy; ob->next_ob = dummy->next_ob; dummy->next_ob->prev_ob = ob; dummy->next_ob = ob; } /*-------------------------------------------------------------------------*/ /* ** Removes an UN_Object from whatever object list it belongs to. ** ** Will probably crash if the UN_Object wasn't in one. */ void UN_ObRemove(UN_Object *ob) { (ob->next_ob)->prev_ob = ob->prev_ob; (ob->prev_ob)->next_ob = ob->next_ob; } /*-------------------------------------------------------------------------*/ /* ** Next two routines are exactly like previous two but act on sector ** lists. */ void UN_HashInsert(UN_Object *ob, UN_Object **list) { ob->prev_hash = list; ob->next_hash = *list; (*list)->prev_hash = &(ob->next_hash); *list = ob; } /*-------------------------------------------------------------------------*/ void UN_HashRemove(UN_Object *ob) { (ob->next_hash)->prev_hash = ob->prev_hash; *(ob->prev_hash) = ob->next_hash; } /*-------------------------------------------------------------------------*/ /* ** Move an UN_Object from one sector list to another. */ void UN_Shift(long sectx, long secty, UN_Object * obj) { /* first remove us from our old list */ UN_HashRemove(obj); /* now insert us at the start of the new list */ UN_HashInsert(obj, &(Sectors[sectx][secty])); } /*-------------------------------------------------------------------------*/ /* initialize starting UN_Objects (as in, we *know* that we'll need at least ** STARTOBJECTS UN_Objects, so let's allocate them while the user expects ** initialization lag) */ /* ** I'm assuming that this gets called exactly once. ** ** That's the current plan. */ void UN_InitTable() { int i,j; Live_Dummy.prev_ob = &Live_Dummy; /* make a closed doubly-linked list */ Live_Dummy.next_ob = &Live_Dummy; /* with one member */ Spare_Dummy.prev_ob = &Spare_Dummy; /* ditto */ Spare_Dummy.next_ob = &Spare_Dummy; Player_Dummy.prev_ob = &Player_Dummy; /* ditto */ Player_Dummy.next_ob = &Player_Dummy; /* ** The following leaves undefined UN_Objects in the Spare_Objects list, ** UN_InitSector will initialise and move them to Live_Objects ** as things are created. */ tobj = (UN_Object *)malloc(sizeof(UN_Object) * STARTOBJECTS); for (i = 1; i < STARTOBJECTS; i++) { UN_ObInsert(tobj++, &Spare_Objects); } /* now to initialize UN_sin[] and UN_cos[] lookup tables */ for (i = 0; i < 255; i++) { UN_sin[i] = sin(i * 360 / 256); /* or does the libm sin function */ UN_cos[i] = cos(i * 360 / 256); /* expect angles in radians ? */ /* It seems that strict ANSI C sin() and cos() do expect angles in radians... ** we'll have to change this after confirming that the compilers we're using ** expect radians and not degrees. */ } } /*-------------------------------------------------------------------------*/ /* used to insert a new UN_Object into the ** objects list and its Sectors[][] list; assumes that nothing critical is ** being pointed to only by obj->prev_hash, obj->next_hash, obj->next_ob, or ** obj->prev_ob ** ** Note: I've updated this function but the things it does don't ** make a lot of sense 'cos the UN_Objects list and sectors lists ** aren't likely to be adjusted at the same time now ** we have Spare_Objects. */ void UN_InsertObject(long sectx, long secty, UN_Object *obj) { UN_ObInsert(obj, &Live_Objects); UN_HashInsert(obj, &(Sectors[sectx][secty])); } /*-------------------------------------------------------------------------*/ /* ** Returns an UN_Object (e.g. for alife creation, missiles appearing, ** explosions ...). Note that nothing can be assumed about the initial ** values of any of the UN_Objects' variables, especially next_ob and ** prev_ob ! */ UN_Object *UN_CreateObject() { if (Spare_Dummy.next_ob != &Spare_Dummy) { return (UN_Object *)malloc(sizeof(UN_Object)); /* What no check ? */ /* No check for now, since debugging won't use very many objects, but a check ** should eventually be inserted here. */ } else { UN_Object *tob = Spare_Dummy.next_ob; UN_ObRemove(tob); return tob; } } /*-------------------------------------------------------------------------*/ void UN_DeleteObject(UN_Object * obj) { /* Removes an object in the Live_Objects list from that list and its ** Sectors[][] list. */ UN_ObRemove(obj); UN_HashRemove(obj); UN_ObInsert(obj, &Spare_Dummy); } /*-------------------------------------------------------------------------*/ /* UN_CheckObject is called for each object each 'tick' */ void UN_CheckObject(UN_Object * obj) { curwhat = obj->what; /* type of UN_Object stored in curwhat */ curpic = 0; switch (curwhat) { /* get keys & virtual keys */ case PLAYER: /* this is the player */ obj->extra.animate.actions = FE_GetKeys(); /* get the real keypresses */ break; /* <<1>> */ case PROBE: /* this is a probe */ probes_exist++; /* count surviving probes */ /* get the virtual keypresses from a short AI routine - ** real alife work is done elsewhere */ obj->extra.animate.actions = AI_GetKeys(obj); break; /* case missile (probe remote control, and standard control routines) */ /* case SUPPLY */ } /* end of switch(curwhat) */ if (curwhat <= MISSILE) { /* this is an animate UN_Object */ UN_Animate(obj); } /* end if animate */ /* Note that curpic is set in the code that was move to UN_Animate(); ** it might be clearer to move all curpic setting code in that function ** (which for now consists of detecting thrusting and braking) back into ** this function. */ if (User->extra.animate.target == obj) { curpic |= TARGETPIC; } AS_SetPic(obj->pic, curpic | obj->facdir); /* <<2>> */ UN_Movement(obj); /* Movement update */ } /* ** <<1>> this makes all objects of type PLAYER act in exactly the same ** way...we might want to have some other means of controlling PLAYER ** objects that aren't currently being controlled by the player. */ /* ** <<2>> Sets the current picture so FE can just display it if it is visible, ** also allows cycling of colors. We may want to move this to after the ** collision detection. ** ** Do you mean "&" in the previous ? Isn't "|" more likely ? ** ** No, I meant to use "|", since "&" would set the parameter to 0. ** ** Also, "(facdir + 256) % 256" could be avoided if facdir was an unsigned ** char which must remain in 0 - 255 with automatic {und,ov}erflow ?? ** ** Elsewhere in the code facdir was assumed to be +ve so I scrapped the ** previous bit. */ /*-------------------------------------------------------------------------*/ void UN_Animate(UN_Object *obj) { tempx = obj->x / SUBSIZE; /* store original subsector */ tempy = obj->y / SUBSIZE; if (obj->extra.animate.actions & THRUST) { /* forward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx += (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely += (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ curpic = THRUSTPIC; } else { /* not enough energy for thrust */ /* FE call here for thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, THRUST_FAIL); /* <> */ } } /* end of not enough energy code */ } /* end of THRUST code */ else if (obj->extra.animate.actions & BRAKE) { /* backward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx -= (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely -= (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this brake thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ curpic = BRAKEPIC; } else { /* not enough energy for brake thrust */ /* FE call here for brake thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, BRAKE_FAIL); /* "hardware" interrupt */ } } /* end of not enough energy code */ } /* end of BRAKE code - end of THRUST/BRAKE code */ /* * NOTE: we might want to kick out different turn speeds, and use a * standard turnspeed instead for each object */ if (obj->extra.animate.actions & LEFT) { /* turn to the left */ /* <> */ obj->facdir = (obj->facdir - obj->extra.animate.turn) & 0xff; /* <> */ } /* end of LEFT code */ else if (obj->extra.animate.actions & RIGHT) { /* turn to the right */ /* turning to the right, so clockwise, means increasing angle */ obj->facdir = (obj->facdir + obj->extra.animate.turn) & 0xff; } /* end of RIGHT code */ /* <> */ /* ** New target code, it's simpler. ** However, this has an important feature that the objects will ** always come up in the same order (which wasn't true for ** Adrian's hash-by-hash version). ** ** Still needs work, though. Won't hang if the previous target ** has moved out of range and there are no other targets, but only because ** you can target yourself :->. */ if (curwhat == PLAYER) { if (obj->extra.animate.actions & NEXTTARGET) { /* cycle to next target */ do { do { obj->extra.animate.target = obj->extra.animate.target->next_ob; } while (ABS(obj->extra.animate.target->x - obj->x) > 5 || ABS(obj->extra.animate.target->y - obj->y) < 5); } while (obj->extra.animate.target != &Live_Dummy); } else if (obj->extra.animate.actions & LASTTARGET) { /* cycle to previous target */ do { do { obj->extra.animate.target = obj->extra.animate.target->next_ob; } while (ABS(obj->extra.animate.target->x - obj->x) > 5 || ABS(obj->extra.animate.target->y - obj->y) < 5); } while (obj->extra.animate.target != &Live_Dummy); } } /* Minor problems with the targetting code: ** #1: Comparing x and y will compare the universe coordinates, in which 5 ** is a very small distance. Better to compare x >> SUBPOWER and ** y >> SUBPOWER. ** #2: This cycles targetting the same way whether obj specified to target ** the previous target or the next target; those two actions are ** supposed to cycle the current target in different directions. ** #3: Can only select targets in the same row as the player (large x ** and small y differences are the only ones accepted...both comparisons ** should use < or <=; neither should use > or >= if an object can ** target itself). */ /* need to add in FIRE for PLAYER/PROBE */ /* need to add in cycle weapon code for PLAYER/PROBE */ /* one possibility: have objects outside of the objects list be the prototypes for each weapon, with next_hash/prev_hash forming a circular double-linked list for each object; cycle weapon would then get the next (or previous) object on that list, while fire would merely make a duplicate of that weapon into the objects list, editing velocity, position, and (if needed) target as needed */ /* need to add in energy to shield code for PLAYER/PROBE/SUPPLY */ /* need to add in breed stuff */ /* need to add in pick up/drop */ /* these last two could merely set flags (for instance, object->extra.animate.actions & BREED) that could be checked if the object bumps into another object, since fertilization and grabbing will only be processed when an object that is trying to do that comes into contact with another one */ } /* ** <> assuming navigation system with north = 0, clockwise increase ** calculate vector changes */ /* ** <> hardware interrupt for AI, note that hardware interrupt calls ** don't do anything directly; the interrupt is just registered, ** later the interrupt handler will handle it */ /* <> turning to left, so counterclockwise, means decreasing angle ** ** % operator doesn't work here, because when turning left the facdir ** will never rise above 255. Instead code is needed to handle facdir ** < 0. This code will break with turnspeed > 256 :) ** ** I've changed it to use "&" which should work on all 2's compliment ** systems (which I *think* is ANSI for C). ** ** Although it is widely used, 2's compliment is apparently not ANSI C. ** There is a good chance that all of the systems we write this for will ** be 2's compliment, however, so maybe we should check with FE before ** changing this just in case we don't have to. */ /* ** <> code and comments removed ** if (obj->facdir < 0) { ** obj->facdir += 256; ** } ** ** alternatively (if faster?) use: obj->facdir = (256 + (obj->facdir - ** obj->extra.animate.turn)) % 256 */ /* ** <> excised entire target code and rewrote . ** ** ** target code for player only...probes handle this differently, and ** this only allows the player to target things in the 11*11 ** subsectors nearest to the subsector that the player is in, since ** this is what will be on the player's screen...and while we could ** allow the player to target anything, the player will probably not ** want to spend the time to cycle through everything that's out of ** sight to target an incoming food source ** ** ** note: this has bugs in it (especially the "last target" part), * so ** IGNORE the target code for now. ** ** if (obj->extra.animate.actions & NEXTTARGET) { ** cycle to next target ** ** if ((obj->extra.animate.target)->next_hash != NULL) ** obj->extra.animate.target = ** (obj->extra.animate.target)->next_hash; ** else { ** search through sectors to find a target ** ** long x = ((obj->extra.animate.target)->x / SUBSIZE), y = ((obj->extra.animate.target)->y / SUBSIZE); ** x++; ** if (x > tempx + 5) { ** x = tempx - 5; ** y++; ** } ** if (y > tempy + 5) ** y = tempy - 5; ** while (Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS] == NULL) { ** x++; ** if (x > tempx + 5) { ** x = x - 11; ** y++; ** if (y > tempy + 5) ** y = y - 11; ** } ** } ** obj->extra.animate.target = ** Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS]; ** } ** } ** sorry for the tab shifts above, but I don't know if I can break up the ** Sectors[formula][formula] without inducing a parsing error ** ** end of "next target" code ** ** else if (obj->extra.animate.actions & LASTTARGET) { ** find previous target ** ** object *tar = obj->extra.animate.target; ** if (tar->prev_hash != ** &(Sectors[tar->x >> SUBPOWER][tar->y >> SUBPOWER])) ** obj->extra.animate.target = *(tar->prev_hash); ** else { ** cycle through sectors to find previous ** * target ** ** long x = (tar->x >> SUBPOWER), y = (tar->y >> SUBPOWER); ** x--; ** if (x < tempx - 5) { ** x = tempx + 5; ** y--; ** } ** if (y < tempy - 5) ** y = tempy + 5; ** while (Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS] == NULL) { ** x--; ** if (x < tempx - 5) { ** x = x + 11; ** y--; ** if (y < tempy - 5) ** y = y + 11; ** } ** } ** obj->extra.animate.target = ** Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS]; ** } ** } ** end of "last target" code; also end of player's "change target" code ** ** */ /*-------------------------------------------------------------------------*/ short UN_NewLife() { /* Called when the player's probe has just died. This routine determines if the player has any "lives" left. If so, it turns one of the player's "life" objects into the player object, sets whatever variables are needed for it to be the player, then returns 0. If the player is out of lives, it returns 1, which the main play loop takes as a signal to end the game. No parameters should be needed, since the object and subsector lists are global. */ if (Player_Dummy.prev_ob == &(Player_Dummy)) return 1; else { UN_CreatePlayer(User->x,User->y); /* default initial placement */ return 0; } } /*--------------------------------------------------------------------------*/ /* ** needs: UN_ReSeed(), ** No, I don't think so re-seeding is different, when re-seeding ** (if I understand it and if we really want it) there's a whole load of ** stuff that may be already set up. Whereas here, we have to do it all. ** ** I put that in because I thought that UN_InitSector() would call ** UN_ReSeed() to actually do the object creation. */ /* ** This was the brief: ** ** Initializes a sector (including "dummy" objects at the end of subsector ** lists), populates it with food sources, asteroids, and probes of the ** appropriate level, then places the player (object #0, genotype #0) ** somewhere in the sector. Also does anything else that is needed at the ** start of a sector. I do not know what parameters will be needed; ** you will have to determine what info is needed. ** ** Comments: */ void UN_InitSector() { /* ** Tidy Object lists by just dumping any Live_Objects onto ** Spare_Objects. (This leaves inactive Player_Objects untouched.) */ while((tobj = Live_Dummy.next_ob) != &Live_Dummy) { UN_ObRemove(tobj); UN_ObInsert(tobj, &Spare_Dummy); } /* This could be done as a single transfer but I'm too tired */ /* ** Just blank the hash tables. */ for(i = 0; i < NUMSUBS; i++) { for(j = 0; j < NUMSUBS; j++) { Sectors[i][j] = &(Dummies[i][j]); Dummies[i][j].prev_hash = &(Sectors[i][j]); Dummies[i][j].next_hash = &(Dummies[i][j]); /* next_hash shouldn't ever be referenced but this may be safer */ } } UN_CreatePlayer(0,0); /* As good a place as any to start :) */ for(i = 0; i < StartAsteroids; i++) { UN_CreateAsteroid(); } for(i = 0; i < StartFood; i++) { UN_CreateFood(); } for(i = 0; i < StartProbes; i++) { UN_CreateProbe(); /* This isn't the only place a genome could come from. This is where 'seed' ** genomes arise (from the archive of previous heroes ? (In which case the ** archiving routines might eventually fall into a different function heading ** AR_* ?)). */ /* True, however, UN_CreateProbe() will always need to have a genome for ** the created probe, so I've moved the genome creation call to inside the ** UN_CreateProbe() routine. */ } /* ** ... ** Insert any other object type you want to start with here. */ } /* ** Pulls a player object off the waiting stack (Player_Dummy) and sets it up ** as the active player. If there aren't any on the stack, behaviour ** is undefined (might ultimately create a default one but I don't yet ** know enough to say what 'default' is). ** ** Default: this procedure should not be called if ** Player_Dummy.prev_ob == &(Player_Dummy). */ void UN_CreatePlayer(int x, int y) { User = Player_Dummy.prev_ob; /* Use last craft from list (e.g. FIFO) ** as new ones will be added to front. */ User->x = x; User->y = y; User->velx = 0; User->vely = 0; User->facdir = 0; User->target = User; User->genome = (genotype*)NULL; User->action = 0; /* ** presumeably all other properties are set-up by whatever process ** generates the members of Player_Objects . ** ** Possible exceptions, shield and energy (always start 'full' ?). */ UN_ObRemove(User); UN_ObInsert(User, &Live_Dummy); UN_HashInsert(User, x >> SUBPOWER, y >> SUBPOWER); AL_InitPlayerGenome(User); } /* ** Creates an asteroid. */ void UN_CreateAsteroid() { UN_Object *temp; temp = UN_CreateObject(); temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * AsteroidVelocity) - AsteroidVelocity; temp->vely = UN_Random(2 * AsteroidVelocity) - AsteroidVelocity; temp->facdir = UN_Random(256); temp->target = temp; temp->genome = (genotype*)NULL; temp->action = 0; /* ** presumeably all other properties are set-up by whatever process ** generates the members of Player_Objects . ** ** Except for the fact that these aren't Player_Objects. ** ** Possible exceptions, shield and energy (always start 'full' ?). */ UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, temp->x >> SUBPOWER, temp->y >> SUBPOWER); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER); } AL_InitAsteroidGenome(temp); } /* ** Creates food (I can't remember what food is like so I'll skip this) . ** ** How long has it been since you've eaten? :) */ void UN_CreateFood() { } /* ** Creates a probe (without genome). */ void UN_CreateProbe() { Object *temp; temp = UN_CreateObject(); temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * ProbeVelocity) - ProbeVelocity; temp->vely = UN_Random(2 * ProbeVelocity) - ProbeVelocity; temp->facdir = UN_Random(256); temp->target = User; /* (:-> */ temp->genome = (genotype*)NULL; temp->action = 0; /* ** presumeably all other properties are set-up by the addition ** of the genome . */ UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, temp->x >> SUBPOWER, temp->y >> SUBPOWER); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER); } AL_InitProbeGenome(&temp); } int UN_Collision(UN_Object *which) { /* Need the appropriate parts of movement moving in here. ** Might need two versions of this, one for set up and one for ** play but I think one will crack it. */ /* TO BE WRITTEN */ /* Returns 1 if the newly created object passed as a parameter overlaps ** any other object currently in play; returns 0 otherwise. */ /* For now, just returns 0, so new objects might appear in the middle of ** old ones. */ return 0; } /*-------------------------------------------------------------------------*/ void UN_Movement(UN_Object *obj) { obj->x += obj->velx; obj->y += obj->vely; /* <> */ subx = obj->x >> SUBPOWER; suby = obj->y >> SUBPOWER; /* did this UN_Object move into a different subsector? */ if ((subx != tempx) || (suby != tempy)) UN_Shift(subx, suby, obj); /* update sector lists */ /* <> */ xh = ((obj->x - SUBSIZE + 1) >> SUBPOWER); yh = ((obj->y - SUBSIZE + 1) >> SUBPOWER); /* This is to get the left and below squares ? , ** (subx - 1) & 0xQQQQ might be quicker. */ /* It might be, but then we'd have to re-compute the sector number if ** obj->x or obj->y < (SUBSIZE-1) when we checked the object's current ** sector. */ for (txh = xh; txh < xh + 2; txh++) { for (tyh = yh; tyh < yh + 2; tyh++) { ttxh = (txh + NUMSUBS) % NUMSUBS; ttyh = (tyh + NUMSUBS) % NUMSUBS; /* Not sure we need the "+ NUMSUBS" 'cos xh & txh are now always +ve */ /* xh and txh can be negative if obj->x < (SUBSIZE-1). */ this_obj = Sectors[ttxh][ttyh]; while (this_obj != NULL) { if ((this_obj == obj) || (this_obj->shield <= 0)) continue; /* Can't collide with yourself, and a bullet's explosion can only hit one ** other object per object that the bullet contained. */ /* Bullets have shields < 0 after one collision ? */ /* Bullets' shields are set to 0 upon collision since they're supposed to ** die after one collision anyway... */ if (ttxh == txh) dx = obj->x - this_obj->x; else if (ttxh < txh) dx = obj->x - this_obj->x - (MAX_X); else dx = (MAX_X) + obj->x - this_obj->x; if (dx<0) dx*=(-1); if (ttyh == tyh) dy = obj->y - this_obj->y; else if (ttyh < tyh) dy = obj->y - this_obj->y - (MAX_Y); else dy = (MAX_Y) + obj->y - this_obj->y; if (dy<0) dy*=(-1); /* previous section can probably be made simpler if we also re-do ** the following if statement, 'cos only one term of the boolean will ** apply to each conditional above. */ if (((dx < this_obj->bboxside) || (dx < obj->bboxside)) && ((dy < this_obj->bboxside) || (dy < obj->bboxside)) && ((dx * dx) + (dy * dy) < (((this_obj->bboxside + obj->bboxside) >> 1) ** 2))) { /* <> !!! */ /* we have a collision between obj and this_obj, so handle it */ if ((this_obj->what == BULLET) || (this_obj->what == MISSILE) || (obj->what == BULLET) || (obj->what == MISSILE)) { if ((obj->what == BULLET) || (obj->what == MISSILE)) { this_obj->shield -= obj->extra.bullet.damage; obj->shield = 0; AS_SetPic(obj->pic, EXPLODE); if (this_obj->shield <= 0) AS_SetPic(this_obj->pic, EXPLODE); } if ((this_obj->what == BULLET) || (this_obj->what == MISSILE)) { obj->shield -= this_obj->extra.bullet.damage; this_obj->shield = 0; AS_SetPic(this_obj->pic, EXPLODE); if (obj->shield <= 0) AS_SetPic(obj->pic, EXPLODE); } } else if (obj->what <= SUPPLY) && (obj->extra.animate.target == this_obj) { /* code to handle breeding, grabbing, etc. */ } else if (this_obj->what <= SUPPLY) && (this_obj->extra.animate.target == obj) { /* same code with this_obj and obj reversed */ /* not necessary surely 'cos it'll get called in reverse ** when this_obj is itself collision detected. */ /* After the "generic collision" code below is called on this pass, which ** is not necessarily desirable...especially if we implement collision ** damage at M4. Plus, if this_obj is going fast enough, it might fly ** over obj entirely on its next movement check, which means no collision. ** */ } else if (this_obj->what == STICKY) &&(obj->what == STICKY) { /* merge two sticky bricks into one object */ } else { /* objects bounce off of each other */ tempx = obj->velx * obj->mass; tempy = obj->vely * obj->mass; /* <> */ obj->velx = (this_obj->velx * this_obj->mass) / obj->mass; obj->vely = (this_obj->vely * this_obj->mass) / obj->mass; this_obj->velx = tempx / this_obj->mass; this_obj->vely = tempy / this_obj->mass; } } this_obj = this_obj->next_hash; } } } } /* <> ** if (obj->velx >= 0) ** obj->x += obj->velx; ** else ** obj->x -= (-1) * (obj->velx); ** ** if (obj->vely >= 0) ** obj->y += obj->vely; ** else ** obj->y -= (-1) * (obj->vely); ** ** I didn't get the previous two if's at all ! ** Isn't "- (-1) * x", identical to "+ x" ? ** remember that unsigned numbers underflow happily as well as overflow. ** (I may be wrong but I'd be suprised) ** ** torrodial space needs no implementation: overflow and underflow should ** take care of this for us */ /* <> ** detect collisions ** ** moved the next comment from inside the loops so I can read it ** ** Need a scorecard yet? What variables are what: (Z=x or y) Zh = the Z coordinate of the topmost/leftmost subsector to check tZh = the Z coorindate of the subsector currently being checked Note that Zh and tZh may be negative or greater than 64, so checks against Sectors[txh][tyh] are not ok. ttZh = tZh normalized to 0 <= ttZh < 64 This allows checks against Sectors[ttxh][ttyh] . dZ = the difference in the Z coordinates of obj and this_obj, as adjusted for torriodal space (we can tell if we need to adjust, and if so, how, by comparing tZh and ttZh. If tZh==ttZh, no adjustment is needed. If tZhttZh, add MAX_Z to obj's Z coordinate before checking. Note: we may want to have one standard bboxside for all objects...this would get rid of four indirect references per collision. If we do this, then the pixel maps would still come in fixed sizes (the largest confined to a circle no more than SUBSIZE in diameter, as is the current plan anyway), but this problem would be avoided. */ /* <> ** There were some bugs in the old detection code: for instance, if ** obj->x == this_obj->x, dx will be 0 (as it should), but the collision ** would be ignored because dx < obj->bboxside (assuming obj->bboxside > 0). ** (The previous check started with ** ((dx < this_obj->bboxside) && (dx > obj->bboxside) && ** (dy < this_boj->bboxside) && (dy > obj->bboxside) && ... ** which also lead to the bug where dx = 4, dy = 0, obj->bboxside = 10, ** and this_obj->bboxside = 2; this is obviously a collision, since obj's ** bounding circle overlaps this_obj's bounding circle, but it would not be ** detected.) ** ** (Badcoe's comment noting another problem snipped, since that problem has ** also been fixed. - ) ** ** The previous is fine as long as all the circles are the ** same size, but if they differ then the centers of the circles are ** offset from their bbox-coords (which are measured to a corner, yes ?) ** by different ammounts. ** ___ ** / \ ** | + | ___ ** \___/ / \ The centers of these are at the same separation as their ** | + | bbox corners. ** \___/ ** ** ___ ** / \ ** | + | _____ ** \___/ / \ The centers of these are at a different separation to their ** | | bbox corners. ** | + | ** | | ** \_____/ ** ** The easiest/fastest solution might be for only a small number of different ** circle sizes (say 8) and an array of relative offsets. */ /* <> **possible collision damage implementation: obj->shield -= ((this_obj->velx * this_obj->velx) + (this_obj->vely * this_obj->vely)) * this_obj->mass; this_obj->shield -= ((obj->velx * obj->velx) + (obj->vely * obj->vely)) * obj->mass; Alternate possibility: Calculate total kinetic energy as above, then recalculate after adjusting momentum, and subtract the difference from each of the colliders' shields (half each? proportional to mass?) */ /*-------------------------------------------------------------------------*/ void UN_ReSeed() { /* TO BE WRITTEN */ /* will have to adjust to make sure that not too many objects are in play at ** once...may even remove isolated inanimate objects (or might not?) */ } /*-------------------------------------------------------------------------*/ char UN_NewSector() { /* Called when a sector has been cleared; this allows the player to choose ** a new sector, then calls UN_InitSector() to create that sector. If the ** player has just cleared the last sector, this returns 1 to end the ** game. */ if (curmovie==7) { /* final sector cleared */ AS_ShowMovie(PLAYER_WON); curmovie=8; return 1; } /* TO BE WRITTEN: code that allows the user to choose which sector to go to */ /* Current implementation: player automatically advances one "wave" each ** sector. */ curmovie++; AS_ShowMovie(curmovie); StartAsteroids=curmovie*50; StartFood=0; StartProbes=curmovie*10; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); return 0; /* game continues */ } /*-------------------------------------------------------------------------*/ void UN_InitGame() { /* calls UN_InitSector() and sets anything else that needs to be set at the ** beginning of the game (for instance, making sure that there is only one ** player life object in the Player_Dummy list) */ UN_Object *temp; while (Live_Dummy.next_ob != &Live_Dummy) UN_DeleteObject(Live_Dummy.next_ob); while (Player_Dummy.next_ob != &Player_Dummy) { temp=Player_Dummy.next_ob; UN_ObRemove(temp); UN_ObInsert(temp, &Spare_Dummy); } UN_ObInsert(UN_CreateObject(),&Player_Dummy); curmovie=1; AS_ShowMovie(curmovie); StartAsteroids=curmovie*50; StartFood=0; StartProbes=curmovie*10; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); } /*-------------------------------------------------------------------------*/ char UN_PlayGame() { /* Will be called when a sector has been started, either ** after UN_InitGame() or by a game having been paused in mid ** sector, then unpaused. */ unsigned long ticksleft, nextupdate = FE_Set(); /* how many ticks left until next update, and the time of the next update, ** encoded in a way meaningful to FE and AI */ while (1) { probes_exist = 0; if (User->shield <= 0) { AS_PlayFX(FX_DIE); if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } /* UN_NewLife() returns 1 if no lives left for the player */ for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy;) { tobj = curobj->next; if (curobj->shield <= 0) UN_DeleteObject(curobj); /* is this the only bit that removes the dead ? Or is it just a tidy-up ? ** I ask because surely this *should* be done at the point where the shields ** *became* <=0 ? */ /* No. When the shields become <=0, there is one frame where the FE displays ** the object dying. On the *next* frame, the object is removed. */ curobj = tobj; } for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy; curobj = curobj->next_ob) if (curobj->shield > 0) UN_CheckObject(curobj); if ((ticksleft = FE_GetTicks(nextupdate)) > 0) AI_DoQueue(ticksleft); nextupdate = FE_Update(Sectors, (User->x) % SUBSIZE, (User->y) % SUBSIZE); /* syskeys that aren't handled below handled here */ if ((SYSKEYS) & 4) FE_ToggleSound(); if ((SYSKEYS) & 2) return 2; if ((SYSKEYS) & 1) return MA_ConfirmQuit(2); if (!(probes_exist)) if (UN_NewSector()) return 1; /* We will probably want to change these conditions. */ /* This would be an ideal place to put a possible call ** to UN_ReSeed() if there are too few or too many objects. */ } } /* Return codes for UN_PlayGame: 0 = quitting, 1 = game over, 2 = paused */ From dl.ac.uk!mbbad Thu Oct 19 03:16:05 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t5rzm-000fJaC; Thu, 19 Oct 95 03:14 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id LAA29193 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Thu, 19 Oct 1995 11:09:11 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@alnilam.krl.caltech.edu id AA04689; Thu, 19 Oct 95 11:09:07 +0100 Date: Thu, 19 Oct 1995 11:09:06 +0100 (BST) From: "I. Badcoe" Sender: "I. Badcoe" Reply-To: "I. Badcoe" Subject: Re: plants To: ag-alife@alnilam.krl.caltech.edu Cc: ag-directors@alnilam.krl.caltech.edu, ag-universe@alnilam.krl.caltech.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi, Just a general node to point out that I'm only online at the end of weeks (Thu/Fri and sometimes Wed/Sun) so I tend to reply to thinks in 'burst transmitions' on each of those days. Sorry guys but I reply as fast as I can. Badders From phil.ruu.nl!faassen Mon Oct 23 12:23:59 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t7STU-000fJRC; Mon, 23 Oct 95 12:23 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.7.1/8.6.12) with ESMTP id UAA25695 for ; Mon, 23 Oct 1995 20:18:19 +0100 (MET) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.7.1/8.6.12) id UAA12834 for ag-directors@alnilam.krl.caltech.edu; Mon, 23 Oct 1995 20:18:17 +0100 (MET) From: Martijn Faassen Message-Id: <199510231918.UAA12834@laurel.stud.phil.ruu.nl> Subject: FE status? To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Mon, 23 Oct 1995 20:18:16 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi there, I'm currently trying to make the various bits of universe compilable. To see what the compiled program actually does, front end code is necessary. :) So, what's the status of the front end code? I know there's poc3, but anything after that? Do you need a list of functions that universe needs? (you also need a definition of how universe expects keypress info, I think, looking into that now). Currently I'm trying to compile the code on a linux machine, with gcc. Naturally the dos FE won't work with that. But, I also have gcc for dos (DJGPP), which can compile flat mode 32 bits, etc. It's hard for me to make the front end code running on that at all, as I'm no expert on assembly code, etc. Perhaps, if we want to support DJGPP that is, somebody in front end can look at that? It'll be greatly appreciated. That way I can get the code to compile and run at my home machine. :) I think DJGPP Is a good choice, mainly because it's free (and fast), so anybody can get it. So, please? Please? :) Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From undergrad.math.uwaterloo.ca!jmlait Mon Oct 23 20:21:07 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t7Zti-000fJbC; Mon, 23 Oct 95 20:19 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id XAA29455; Mon, 23 Oct 1995 23:13:52 -0400 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id XAA03809; Mon, 23 Oct 1995 23:13:49 -0400 Date: Mon, 23 Oct 1995 23:13:49 -0400 (EDT) From: Jeff Lait To: FE-PCX , Art Sound cc: AG Directors Subject: FE/AS update. In-Reply-To: <199510231918.UAA12834@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hopefully I have the relevant parties. If you know of anyone who should get this and doesn'tt, forward it on. On Mon, 23 Oct 1995, Martijn Faassen wrote: > > Hi there, > > I'm currently trying to make the various bits of universe compilable. > To see what the compiled program actually does, front end code is necessary. :) > > So, what's the status of the front end code? I know there's poc3, but > anything after that? Do you need a list of functions that universe > needs? (you also need a definition of how universe expects keypress > info, I think, looking into that now). poc5 (Even numbers seem to never go anywhere :>) is appended. It is not functioning as I lack the v5 of Universe code to get it going. > Currently I'm trying to compile the code on a linux machine, with gcc. > Naturally the dos FE won't work with that. But, I also have gcc for dos > (DJGPP), which can compile flat mode 32 bits, etc. It's hard for me to > make the front end code running on that at all, as I'm no expert on > assembly code, etc. Perhaps, if we want to support DJGPP that is, somebody > in front end can look at that? It'll be greatly appreciated. That way I > can get the code to compile and run at my home machine. :) If DJGPP handles standard obj format, you have no problems. At least, not TOO many. You might need a recompilation without register passing or some such. (Thugh, you can probably tell DJGPP of this through pragmas?) > > I think DJGPP Is a good choice, mainly because it's free (and fast), so > anybody can get it. > I think Watcom's a good choice because I detest AT&T synax asm :> Anyays, without further ado, the folowing prologue is also in the uuencoded zip, but it is placed here for the people who inevitably have problems with the uuencoded file :> Unfortunately, I seem to have lost the v5 c files, so these are up to date by the v5.1 header & v4.x c files. FEMAIN.CPP The attached FEMAIN.CPP addresses problems for which solutions have been given. NB: Set tabs to 4. NB: Coordinate systems: Currently, the object coordinates/65536=1pixel, I believe this has been decided precisely in terms of screen position, but I can't recall the conclusions thereof. I believe this was correct, but with 1024 pixels being defined as the width(or height?) of the screen. The current system would then be off by about 3-4x. NB: I haven't compiled any of these changes from POC III as I lack the required universe code :> BTW: Trig functions take radians! Degrees are about as useful as gradients :> 1) FE_InitScreen, FE_Init & FE_Shutdown need to be called 2) FE_CompileSprite must be called with each 128x128x8bit sprite before it is used. An example: shippic = malloc(128*128); read(f_id, shippic, 128*128); object->pic = FE_CompileSprite(shippic); free(shippic); The result from FE_CompileSprite is a compiled (or in the case of PCX, split up) sprite which has been massaged appropriately. (This is where a platform could generate multiple sprites for every view, for example) This needs to be implemented either in Universe or AS. 3) FE_IsKey is currently used to return true if requested key is pressed. Can be quickly converted to FE_GetKeys by something along the lines of: action FE_GetKeys() { action result = 0; result += result + FE_IsKey(MSB_KEY); result += result + FE_IsKey(MSB-1_KEY); result += result + FE_IsKey(MSB-2_KEY); ... result += result + FE_IsKey(LSB_KEY); return(result); } If that method is desired. What are the codes, anyways? They don't seem to be in Universe.h I need a description of they keys/bits. 4) FE_Set: What was this for again? Isn't FE_GetTicks sufficient? 5) FE_GetTicks: No timer code in current FE. Wjat was the NextUpdate for anyways? 6) FE_RedrawScreen: Same as Universes FE_Update with a few small differences: a) Redraw takes a pointer to a `ticks' parameter which it sets, as opposed to Update which returns the ticks value. b) Takes a pointer to `you' as opposed to coordinates to center at. c) Note objects are drawn from the CENTER! (Universe hasn't changed their mind on that hopefully :>) 7) FE_Update: Wrapper for previous. The UN_Object may be incorrectly specified, despite all the debate :> 8) FE_ToggleSound: No sound support yet. Should return new sound status or something. 9) The keyboard handler is screwed. I've had problems with it crashing, but as I seem to be alone, it can wait... 10) Move FE prototypes out of universe.h & put them in fe.h! 11) UN_Cos/UN_Sin should be fixed point, no? 12) What is it with the thrust table lookup???? 2billion 4byte entries would overload the virtual memory space of most PCs I know of.... Portability: So, how portable is this interface? Well, way back when (Around December last year) the FE_PCX people of the time decided upon Watcom C. Thus, the C(++) code is designed to compile on Watcom C++ 10.0. Beyond nonstandard commenting (//) it should be pretty ANSI, and hence compile on DJGPP. However, the assembly core is written for TASM 3.0. It doesn't use any special features beyond very rudimentary macros, so should work under MASM & WASM with minor adjustments. DGJPP uses AT&T syntax, I have a script which converts intel->at&t but it would probably require touching up afterwards. Furthermore, the asm code assuems a register calling convention. Watcom's implementation is as such: eax edx ebx ecx stack. Ie, passed arguments are placed into said registers respectively. You can simulate this by wrapping the functions in a standard stack frame & pulling off the parameters into those registers. Needless to say, the makefiles are non-standard :> ARTSOUND: AS_SetPic: I presume this group get's to specify picture format? Note lower 8 bits of type is ignored as we don't care about rotations (that's handled by FE). Should this get more information,ie: frame counter, so it can actually animate :> AS_PlayFX: Won't this need more info? AS_ShowMovie:... So, who creates the sprites? Shouldn't it be AS, either loading off disk or retrieving already existing sprite? Same goes for deleting them section 1 of uuencode 5.20 of file poc5.zip by R.E.M. begin 644 poc5.zip M4$L#!!0````(`$Q75Q\A[I,0\`@``$81```*````3D5%1$5$+E185(U7;6_; MR!'^'`+\`_TT^6)+M2+'CI.F*A+#4>Q4=[4C1`J<^Y1;D4-Q(W*7MR^BB*+_ MO3.[E.3K`6T3*)'(V9EGWIZ9_:H*;9Q7PF'5C6`&%K$&IZ$46X1*6P>N1-B^ MA@P*6:$=@=7\R"((@^`;%L[I.*RZ-(FRXPLH4>1HX`2V5^/=_NPX3?COW>W] MS>QA/)W/TV1)!X1S(BLQA^,+$'ENT%JTT!B]JK"V0$"A+656$H+*.ZF5C2A7 MB"I-UG*+BBP\?)C``@FV6%G&=M4_FVIM75Q!P,B:IU@2JD(I`B:",Q')7#BB*)&3GI%N31\2N<(D_=I M\F'Y.(&ED6LHO,IB[IW8(!B12Z'LXN%K_C;FB7)+9LF MK)#"-82[V^\S)=TBN#_:_X03_K8HO`(BOAXO+MCC]O5Z3;1N$5%IIPT@-)@`AE3M&_48`[43<53M+D MF2UET\@,WD%-&G4V(!U_IL_P;_32H,@'Q7>9CZ"7&\'3][&07[R/"OX3ZZ`_ M$T0+M76*X1F$^_C=+$-A5YZ)OA MWNW8OH>FJ86U8LVETC1&DTA@(8K$8,EUSJ7./0`B39I*.`I935:Y'->HT(@0 M]4-A,)ZT%L#5C);5;N*))A`:)3I-IB(T MTV]>9AO2D&E%UEQ40T8^H2,KEAO-ZAI=R_U7NQ<7_+7EYD!R/ MQ_]#_A^_0\#!'$2A\.1?])DQG0@''!.=* MSEX'9NL@UTQ0/.'2I,_^,=7CD@W$=A>L-S.R"5&,)-9Q'NWY2KHXQZY"/2S0 M3:+I-K"LC!4HUD(J,CNS;#&F9TG)MF!]4B:M;P>/GT[@0<-3M9H(O41 MO#T;W]VRCS\.AA`><.>^-F'TDLDTV3O+:M\$M5\P-Z*-]#:!A:B1F7#OL&61 M7D%@*P$%MF"9;B"718%D.$/+9"2&$)4%UN7N;[14CG!2'`7\ZAC]*33"D!%^ M'#N="0\=)\*FB6X:W;?*WFH0BJF./@4]L!651ZZ6U1"6?[3W:Z?]*7OR1..3 MD1U^8A`6CK5D0PJKVT_W."'8%Q79C>U.;Q^6MU^>`PP.G5^*D+LXN/*PVD@# MM50Y:!7+L-0-CY>J@\G[(8?]+\-C3"?P:$33$`HNB,;@5FIOXY"%KP_?/\== MHQ9=+,1^HE<=\R9FLI"8C[@.&V;._8*0XXHC%T?8VV!NJ=?K"A?:JSS4C^5O M8#T%QSCHT)'-11EHLZG?+2IUV7<-3A_,>383K4]I_\6 M],I&S\EH(7>\H'$=C4#IT"<7E\/8O3QNXB(5Z[`T/,Z=(+>@TGKCFVOZ`W"Y MDE7%I'"UZB@/J)R1!#`L26E"R$VE11YW9FF<%Q746&O3@6U$%F9CS4OU?,HA MV2C=TJ-Q[_V<$B;(@'0=-]U"CZ`D@28\KL+8#0P3.J$@=03H$:MJ1"'L8,6+ M5,M[VN#&A.Q^Q`SK%5)R*V&Y%(09!FAWM]_GTV_0H.;1V6^!S#N'/=8WY..C M<)FN81J*UMM17-.F@[.S8<]/D8#7:M^$82.`)T?/SN#BY?@E:?B`G29,2BOK MA,J%H7B1"(]>'F^#\_-AX(M#OAJ#SG5P\["8,9/G4#(=/37R\:=/\SEW^-]U MRS,_+O'"6O(ZC%43(+9&.D=AX3Y4@#HL%,;GDN$*^EZ+S.AX&>H1M]IL@**.!N[9R$F://+_H:9JJ7@JY#^\ M=:R">>#CIY_FK=J%^E04"<0)$E.59A28C9KUZ\%^[$A>V? MZS8@X"X4['B_2%-*?!9V!]^`*!R:EJ+.T^O9G3>\ZM04H7W0ZIA2BI[G3A:D M92TMLRAOM*PE(%`\$GF'B1D^M<<-2H1IR;LAC[FLY!I&L0/,Z;.B3[9CPLDV MC&!&AAM.50["K'T(2F#FIA(9/20O*;1"Y@<&)QLAH?O>0;#A\[S#(;L;A26SR" M81\>$/,*;9@X5O1WR%IL,-QV@S=*JQ<'BY&U;[XL%Y^_/GRD\-PL>(&8RXPO M4+P?4ARB$VNC*6EK=*=1>Y@('30RX[KD4JX%;Q#/GH715NF6$O46>#L)_=PU MH?3E6FD3;X`M]OM/=KPA&1V39M-DP!/MU/9$GW,4[VZ'Q]$14:&#.G25B@CX M,BMQTDOCZ"+/YY7H[KY-X#&@9&-M20V8P#OSRL/]?[P&S3ADN9#>+T7ZS9V[>YSB7=A,>'F M\&WS?6O<7C!PK='U]U6GRIW\#4$L#!!0````(``!7 M5Q]:CY0>=`$```H%```,````159)3%5424\N34LQM9-13^HP%,??E^P+W*R';2ZM64K#/WT=C,,"!M1U(88>5(AZ0&-P?W=S M.;P=NI>F`7WLZ=D/=ASZ5&7A:R.)P8Y:>H1@2[`5V"G8,],H18DHX]4LN>I+ M^068TU3*L^XY;)@)A'\:]9?\&MP6N4)#&3"GD M>KO#N:]?RKO%^DC`*L_`*E+XE799[1JXQ.KOEN6S(YV8QL;WV-^(^\N=/X>^ M[E,5[1]GKX]0D(2>%C+_` M^&$,^C';CR`D1!``#<-LF2BGV[QHY:=TB8ZNAU[.5]6BC_O4$L# M!!0````(`"=45Q_]>ALJ#@$``"<"```$````05,N2*603TO#0!#%SPWD"W@: M\-(&2:["G@HVMT(A"H)(V>Y.DL%T)^R?E")^=W=KK0K>.GO9>>^W\X:MBJLK MSZ"`I?4-!Z.A1ZG1EDF\NJH\NZ76:&SA855OETWL8T,&+WV>.6^#\C"2\L$B MO.?93/720J&"C:*8S:H*GAQJV!VA7I47O[5RC^[E_E4DXK&WP7E`KQ+Q(=+H M**_)*1P&-,C!P2FD8.*$ M1JXQNZ`1``#B/0``"0```$9%05--+D%33=T[77/;.)+/2E7^P#UU7B8?9C0B M9*/Z/0B@>P7AA%IX??>PB"(`C.0;'4'&RB0\5Y"N-B,N&$>Q@C-',4\S(1.9)" MFFW@1C!X:5Y`,`(>-H:[B41%R;!?YU.M[\WR/!Q@X)62M%P4_"J;XU\X! M1%SG'A`-/8@Y"D)W:<%)*O*OG8Z9?.O!(C'$+#(/KODB-_?(EV=?QD4>R7GZ M=GEO+0L5\F4H/'^M6!9_Q6U%FL-,1LMS:G;[ZB99@/AD@;KG:V'O M"/J[`Q]>G5\Z:;CM!Y`C2LMG0%PO9,YR'MT/^AF/ICQB.5L"\$[>\,N<*5WA M3^OQ(2UF&D?HPS-\7+,>2=Y>KSF/[)X&@-O<+GSXX.OH\.K0S)C.4.@SIA@X M:(7FYHR/L'V9@^(--L@:L.1/:')X3#KUR9'G`OVL@N&N@7P]LDE+OBB0762)"AAH;[#5V M`=[PA8+$YU$+O>GK?O^>:E[_F!Y_<]?]OS=SQ_X/F[GK_G^?M>T/,"LR;P@KX7;'O! MCA<,O"_:\8-_K][R^_]O#!QVW1T![@-G*//4]V/9@QX.!![L>[.&\CKE@ M4@O/G.)X]@11>[8/6[3^J9ES?#IZ]_"!_;_4DCR-]&:9X.AL=+Q)O^+KU?'' MJ_NT.6[X&$G`M"YF'$(]I#4>1.8)3^D!=T\;YO?#HXNS#>K\3>)V=7%X>OGU MW=GO>!F=$?FTUKH;$G+R(&XX3)2<.0N.#(Y6&?WW;1@O\AQ&;_$`(5-JT2TG MQXW)YCF*S0C(NR1%';(4:.4X@TZVN]/CZY.SD[_ MC_*S-?,CGJ"/=P!XYQJ.#S_BK3-0U@F(<)@B'XK[G%&1J,`U*)%E/+(L__)H M:POMRN8P;."',5UH+BTK=(SW!SPTO^/R'LTG#_P=MLW[.W&3]2T(?%,D.`OY M)U91Q0>6<3HB#9U$T,JQ%1#DUBN9F2F.&,3./P3*[E^)&\T?M^97J-K39&8_ M\V3/1WRJ>-XF!4^C30>$K8`(GL,1(U<,DR8H5C=+,YZ4X=+3`QS&'T#&(2YY M.1K".W;-;6`>REF6");F&U1\2_%;R1N(E-^+2Y(MS_I99,-`ZFZ2X>B3,&8* MGID[M@]5@&L_EHY[14RBI?E[/*+_7W[<-.DHW"[)A@QX6V)4\!:JL/Y\6>%&EU6DX:?S=@7#VJYU+3G*\6Y@9WP,)=JN*0SFOC[ M2\@>3IE(\=9Y>.W0#&6$Z0T+/G1$8D3`8ZESJRJ!PEG"E$PM"C<#%AMWF"8,>>H/)QHEMN'Q=]&>122[IN8V)%VE3.D5UH6B[":Z[@%U"<-LHI5\PCJ_U;-X5T MUZ*M<:QP_30E[7)?]RAI-^,)Z9,-;;^4>&N;8W;;-,F`257=O+&*>]S+2'LU MEZV[Z_;UN6LP[V*61@EOW"#NU;"6CN&:ZK_"N+H0>#]-%M;]G$MUC9)$@AP;M#+%ZA`)L!O1,0W:AM1+.Z]'46W!+U2?43(9TI4!2SP8H/T]@-'QR_>O6ZJQ-^Z9G]@Y M2"\_71W#^=4%?#:#95S2>KD5?#';)I0'/!U9@'?8C00GDIRC.:KP0RZY#>,I MX<5BZ__C\UXO+K7"-5^,)5,1L/`ZE?,$6,'W%R\!I&#X@EGFK\PX]_2[_!WKN11S!0+* M/AV]LC#%B%07N,&,Z,!7@A="-F,@48(H3CLQ.,0\Y/ MCKINH9GF%I;"OR+Y0O'<&9;S`J-/^(#19@0Q2R98;XIEH6#,)U)Q.(%4YB+$ M2AM&-E@P(^E!36%AG+X"621&/IE,$X8>$U8!F-I=.$0\C3'$NSK*QIR`G,;V.( MQ&S&4ZS3;3(-LE)R:JL_X@_1]%0LJY`LH&#W;6#F0C*7;+`3H]OEL7:T!G:0 M+2_\;%X]VX:MTE=IY$*_K/A'T,$R3/Y6RBSH^R2V+LH5R$GOI[;RV*G]*(M7 M[4G1$G1+Z)SN9`:-5O(21R(>.L5)"JFY;^G9H$<3+AG1)FU_EE^S5+N#YQ#> MQ;N-:2T&ML\VU]5@X$ZGBJ9<)=O6'%(Y[P(@P.4TGB;872SW%PFQ]]XF&MXG/T-*FA72MJC82***?T0S]FM(SL7Q^16XZAFRTD'E M11M*13SC*?HT4&0RA0;SV;2[W^_9O/NV!WL>^`&F0=`$F%_S*K"9]TXCM_G9 M;+U%"[^@9.GR`\ZS*3O'\HAP8[]*#,KL/8E#E;.OV7W9@5\ATL_B^;JZ7+.[ M\^8!;E8FWJ6.-*^LCJRXQ.E`4H>L4H<.3#/&6\<>S;/] MS)P2%>>?K!3FL9SOBO-E9?^.6V_>][H;!Y>=%-^YADQJ83NK?K'1+C4=89\, MM1)LW%[7[0=_Q"!A*V/?N+_J.O?6)EMKZ[8?$&N@A+5SWAUKBJ/:IE;Q2KOP M-]C9Z0^(9<1-R3U4/S#[?_%L9:-S`!__U#9O_JEMMK;+C0[@TUW[4,V#4F?] MB?F)6P#VOE19[4N\81RL_9?M2D)8F9JNE_I!O?9()K*@&+R^`3N=Y"E(/GH0 M?;*OCQ-.H;=Y;=Y^\NRM>([`Y*N\')*_DG$UX2%Z!^APB`0]#T24`A-2B/K: M=E$P2,QF."Y33DD.JOY+8#=2N$!G3GHTQQ1]/I>0,:VY=HUW=JQJH$LE=1;, MIEUDTVR;F:F[O9O"JJ.ZGN4D7`Q]E]]JI= MAVHH*Q1QTA&D'J*/U?O,*X6:!CXMJS,,[%%TKKC.@\%.2YT-!K6EBVYK0$XO MU&5?N[%32W48,V@+_J`E^)_-G+M"%P/JS+Z5$[IO#+#7I!`BL65@81JA2O"6 MLY\];([#,=:=;U67Z]5V*=\#M$G0K"ILVVRX24U%Z.&"3&_ MH+KPVN"EH??<'W1K[.K;7J_8<8^P5N[NM-9TSK)[3_=M[(BS:S&D0/C?CQB[ MPSL,/V4>/SH.PAAS#I^&:YET'9>Z;!-I@54>76%*4AHH[=TF8_9[P2HCEJ[% MF__OM#>G6V7$-:=SC-CW_55&_/*_+.1A4S13WN)T-T_\S M$UNNT7LERF^EM=RD)>_TCE;P9G+6]0FX1@%P?6E:8.,%?;\E?SYC&>::"HW^ M5*9X:+\E@YIBRJD0Y#I\L)\4YZ(OETM*?=&7-,8+="A=T9H+;#Q%7X_F2^6^ M08,@*H#@]E#U]R;$##'#CE7.=*'L-V]LC[R.1:8I'Q;T0!O\4NOH`?F_[UUO ML`?S7P&=,ZZ'X/N[O9V^G51.0!=XNSVKWQOL[*Z=I?C,7']4Y?!"GH8+:B48 MPO]L]WN]WA#.BC!^].C1S\C#E=W_]SN=MLN!8SIM6#V;%4@JY!*14F/P\`[W MU$KH^-;ZAV_HRQ=E3ILMY[3_(&U=B7PC@5[")\/V`;_BL0R]SJ:[(J(]C&/L MX6K>IYHATE!1A*2;U4DZC4_IOW`>\:9'[33F&W-(B&YO6VT$M&R`1'@K600Q MSL'2*`47"=9XI.ZN;-/'!2R&O^`46H--G.3^8B<'2\P(O3;#W:I$FC&=0TQ! M7[>C\`%W?NX']7T1\QXJK`/8'CQ:)_"K2WI:(`M, M\;M.*9],1"BPG$Q^2"/\[@V;507+9+9V5N?5="ZM+%\^?X=_M)SQ/$9]P1/- MV^%^6;6M1'%3YF+J,W/D6WGZ'XS3JE\;[+`P9%JH8M@HH3E]B M,Q3_SI5\5&)5JI,>$7EWQV[N__#FE83TER'[+S7##PQ8"V&"\?+`?Q[F[ M@NC=&.X,!FT,M_PVCCLN]E^+8_"OP1%OMX5CL(1CB<$Z'/U_#8Y[VTLX]I=P MW-M>Q?$`-8"+X6K-9B$U_,PE1].2P^J.856)K5JA1*LJ.UZ*Z%:+M`>-H7[0 MNS^MVFOV0&(+&Q;@RK;!/_9^6UY(Z?_BMU>`ONQ!SP\?_,?_`E!+`P04```` M"`"J;+4>AH*AY2`!```$`P``!P```$9%05--+DB%DD]/\S`,QN^5^@4X6=ME M3$B[PPGHACA,0G3WR30NC=K&(7'V1XCOSMH,\;Y":T^)'?OW/'(\U:515$*V M7&U7R_M\G2;34ZP-_9M*D\4"-I7V$-\\2$5@'0O+T9["DAU@T_1I]"V4P13^ M-DWH(.0,3!XG\`D[U@IZXC9SN,\_`CJ:%14ZF"OR<@/:".SC45W?P==EP+/1 M,NOJYH>&N0XV=LV//U'$UG04?&MH&)9703+>F]EP66=ZX]#XL_-.\->WY^"* M,2&2)X>VZEM;5B/E#XV6O'!$YK\IQ7O4.VO7VHYXYQ='!;=6-Z0&:#$J1JUU MLWAE01FD]5]"ZIT4"@X#U[RC7-#Y/PMA0GLFC5.ZM8B4?BQ$ZC)C2D;I,DVN MO@%02P,$%`````@`KU97'ZRJ$Y)=$@``FSH```H```!&14U!24XN0U!0S3MK M%;YRSLI0FG^0B\? M=#B+9!=.3SXI4:-Q`NV??WX% MGXS^FPP2^%7'<%[?))!C:0.CIHG2<1?Z8V7!_1-1!,E8ND$V/AU=0:!#"?.Q M"L80B!ALHES_P#49E20R!D?&?50,1Q#.)"0:5/*CA4@$MZ"'$$L9PE`;L%-\ M&LP23V(RLXE''N!@CF8@9E8Z=.1"3::1G,@X$<@=8@=JJ`+B&_ZX;+>0SIIT M!'`A[Y1%-B]DH$U(LG5ME6.1R`JIIW(T%O%(6M>QM[>'__VM=FOKYU>5OTTB@$I@I",2PIB6P;_>]*$.9^='[R^/3WK==;'V9Q4'T2R4 M\&8BHD@'F^/]I48Y66[YTU`*Z]K^5*EL;<&!GQ24A%V"S6-U)8R4".]`C'2="Q18NS[]^'-"&"N50Q0I7Z1+B4.;T M>XF(0V%"7.4E/:Y+_L[7L;BCW3V0,'%3@)&, MI5&!&_7/#`>]3Q=G_9//L-VA6?]W7T42K/J'_+$)PNU@9&25.`I_7IV MT?\,`&VF%*K)1,:X2PG\3IED)B*/!BJ&Q+%K[^&_J_Q\G[7>?U;\1.N>5U*Q MFR:2U0X."2'!09HL$9R(154T!S6H5L4;]_,+5-UW%ZJB5BM!J3B'VO\FE!A8 MU^!FYZ#@#;0(;@-A'H!>GI^>72&P`ZWM[[=W:KPHQWH6A?&/"6IT+(V$[C[I M_M/'L_/^U[/S+AQGZK$P'\O$`8&`J58Q6V@GS-`I^.\SX9#G*AD[K4PADL,$ M1`+55K-5XB*C6ETT(6W"O`GC&OS7#\\JU>H"]G$"+UZ`>WP#M%F^Q#^+6"07=CAG10RBM,F(0R9("'$K_Y.M;,9$TT>7F MOK2)BD?KW)B]_L7E4?_R8HU[G ME^='_;./Y_#IXF/_8__ZTTEO7:P&8V&@_A8MF4AD;VI4(H]T**NXQ.QQ#B*GT4\BF1M]X=G^%(@GX0C>2P2\;M0[[0*`4Y/OE[(T(AYCVQ0M7`I M]:$RUB/%5_[WN@EVK(WK351P:PLZ!V'82T1P2T/7+3XR"C]',N;74-I$#X?\ M,O?L%62.]2-4$'3=REW_\B.6%Y'6M[-I$^HI/^VBD>@;$=N(`\H$;0,,9#)' M\W_IO3P$6IO0PHO"G4#VJ;"EZ1\>@XX#"7/T@0DD8X$AK1&H9QG+$/0LV?1K MZU:F--"7=N?US2[AMT&ALQ(Q1]93(ZV581-:(",K,\0$62VCXL@RBBS,K(_& M'>W,A%D8:;;`<^(FHVXS@DV5I.9!-OX-X"QQ$T6DD M1K`'+1KT*(\79C%%"\(B%4/`E**(.)V+U&9DZD8G&"B+1"#SS#IN2L`FRD`( M`G6/HMGDU(.8/-5F(I(N<*K5Y>V[E>W<0-LMJ^("OE(!@!/.3KI@30"TJX9& M!`X\M`F_XP-1\BSB/C+(S&X>%9J"N8F^4_$(16,LR"3X'G_APE%/2P#9)V?J MJ@EH+C#EP@E$>F;6N7A]^'J,_I"61O5%8;2^L"Q5^^:F"=FS$WCII7.#_JF" M,BQ)%@==HV"]:$\Y7,3GRK&6%@0$8RFFD$C:_=[4Q",0`Q6I)%V/=ROTX!FH MLG&W8S4M1QBL`^[#]@]9"M-QG-^MJ[$&[U:IO=UK0@/8.=10Z MN6#S6D50#$1PQ)+)I8&=!F!K:U7SDZC@+%:L@OX8'7<\5",88NX5H[V,HA3F M9)02&47L-D4"1K)Y!;2J#G+>)'+HH:R=322X^2\ZK=9Z3-*2QI!?+WWFM@8/ M=XL:.@UQ+ZYFOV_(RI^-W,3DYB:Z!G215!D"C&]@-N6`QG*O#W^\N4%E;9OT=VAV M4G9R6B*B2W(25&-I17,B"Z+JNB9Q8F52S>+()K2:T.Z\)%V,) M#$0?1+>)AO9&V\GH*@K_VN/#12W/HM>8";!C?EM^/<=J=>K MOB!`RO\NBF,ERTNI0%:LHX=*[KS:65)RR7JSDA]DN+[\E?'PKNG0EQ8Q&CHE M(BR)43S;Y6"(@M^'-J9D7=PDJGEMIPXOH0$=-CD9^I?63>;3\Z9VWL3N"H?' MX-I66XMV9_OESD^OFWG)B"(&PLLE9<0`G2?YA>X2E6J>1Z;90[8#G\BG]<:S M)-3SF/S:J=.V!:=_;5(WLL+T[TX&B3;V"=Q3-G1UE5MBF?1DXJ0U'3O!;I,` MAH[#3$A%0WJ_H5B[W/;H(B2LY958K##/BV/WF-A]NNBBY[-CIPLW=:Y^9YB',D".RS(&QW9TT3OXJ M09^&*$[QN&>EB='*JG]P"@GG&&,(+.NX+K#$A-]`,!&Q(V>:6$J0(AAGW1B7 M6'^RX3C#G%UR4*ADEP>))!Y^O(3M#O5Z3$0:<5D]A3P[<[K^C9%#52]TT[_BP0B%?NPD2C=G^83F!?[ M5YER]D)EO>*`9:3N9$S5/2H0CH6%`5H<7RGDA7XHK`HPQVG2[K&X?506]^EA MCFYI4['=RDJ.1OY]YB8F0U[E(@XQ>PT<$:?M9*F`N'KT]2QJ="^9(*I9M=0O M8R__O'Q:"L)75\M&^TEFT]>C421[>$%@S?,H4;XWE=:3S.1R M&@KOE)U6NO!!WW&$SGO=<:7I))@,X5IGRB.73[BJ]=YL8#F8K7TYO_S0NSSL MW7`5ZTBBTW7]/>J_:F9WC!YT76?E6CH8HW.Q+!>8Q5:-\#@&T>QLL&CB=]HD M>\_O_BG-CBKP5,5F7)$0?*4%SQOXZ*&+Z6T(L^E4&LHG*;=QU-RP]]F&C3PU MRZY&U&'GU:OM'=B"SBXCI@\1KSWBN\(7KT!

^'T\`T=5.[SVH07+/8LG3JS?`6`+@>$:CB4 M6+3!H3/!KQ)5XS%1Y<@XS=[EX:>/GT\NL@@E[WR^1ZK.*\J/S#7#^\Y\'YDP M10O9.EJERL9CJLR1OS.QU$\L?7QB&<:CBOP]$T,65O"`=S(>B/S_PMJ:Y+ZU M!1]O1=J$@0AN0Z.G@`/'7)ZV,(CPAF+8Q)P"_?:,:L+86DKDBH3_,,KSKOLU MK==&MG+=I/P%G6@:^1*TO17,I1 M[T#"4,54I`DWBQ0M4O&M#-T/GV-HLM:8Z!!A(T4(U8,8@5[,%&VT%?TT,> MBIWRB$$D\3"W2,)Q666'9<6Q>!->+)V1+V7Q3JJQG)=<2U[I)]W1?5FGM8`N MDM+U.1$$>B+0L_KE7;['$$I&KK)?PS-:?W47<]10#NA:*=[YJL0XN_AW^*L8 M9Q__#O^$A@-EAK*JL?3BJ[SC.N]@>@\+?(B\X5!JL+\/G>P:@K%X3(ZEZRC% M+'XHG$@$3HRJWL*D#\J".)@C=%TBQ%JVFYMP(9$<'I#K".1PB,HG@;!!P/"( MZXCEVNLW"HFE.99FA9Y8_G@GR01Q!!'G%ZR'D=:&TJ^JO<*E54.Y5''E.H:] M[L_UO`GYI0>R6VC`%=%Z]NG$*VNHTN.*/>^=1^'8!3PN- M[R,2X,+I1E^Q0:>U5>I+L>^:^]@/7<$^[5GO@*[@#2R;X(V\&Y'H1D35D26L MS&U=>ZQWV>U-QDHS_U7);P]\>]LV)A:^XQ M'A4E0M=H&?/B1=YAD-*]4SI4H[.T%>>V90<67S7BZV6N;YHTW%0%&_ONR?WF M/.%`Y]EYK)&)41+O$:O@%@(]BY,F_4D`51T2-9&& M3OI2F3`=$894_P M8"]+*KMBM,Y:R?_CJF'AZ\(%WAE:I'AQB&X/^:3G6$:)P`6-I:YN7DHD'(LI M$\+Y^TI<0LOL1Q?:.]WVSF;F3!%:>_!O0CL0HT88=^1\(3/Y&"%=PN4SS`*5 MS_.SD4(TB..5*.6+6YOY"0:5/?-9!$Z$P3CKK:.BFE`W,O&54E)=Z>H(-LE0 MX3[CD_A*Z7X:]N`6M#(?;X#A3U&NH/^0D[D9$!7W20[EZ'1$PC< MC(Q\_AQM"%5FF0;=$%DLR#Q_/=+VRP9?Z^#VE-M[*EYJ3Q'>]?(+`FTX&O0V M1WG@!7;5KKNV&C3H.KOJN#>TP_O[T*8\-AR7(=,ER+2`K.3Q$TV2KO>C/.C\ M%CY3D9__[*+K%?+%Z[C1P!@AI-M:*]K'WVCG>:SJ\+O*"6G+"03N1#23EJ\K MT-]`)7(ZQ?`+KSW`1/"Q-9V7^MV&^M)V0>*:;W6@?D_FL.'8RMI+,G>2J;+> M.UDLQF&)39=I+>,4M,IC.%JL^7O$*.((F:!#W(40;^;3,]'"AKQR3Y-P4^'R M>THOM!H\F057_D.\\A_.T3D_S_]&H&H7](<*3:C:U#]Y0\>,U1"Q."1P8S5R MO=!HC7SQ><>4KP1_7].2BUFA1#7>_$*#,"?YC`5+K%WP09B9TI MJYUOK$81;Z=5`^%(+Z"U&+I/#=Z\P3%1]F[.R,'K6M&;L3(G5D*^94:CKZ8= M+@I)+\GXB47,_!&=!YPQ7[`!Y<:--IF+2LX]QY5^M'3A7WFTE$?[C8W82AOO("E<,HGW9GYCVW]^>7[]\7M8Z)G`33M.KZ MFL`^ZUO$EZEY8CB8CYS^[7\!4$L#!!0````(`.M65Q]X7TEZV1```$<=```* M````1D5-04E.+D]"2IU9#UB45;H_YV.`03%&'2=$3-H^6VC1A<("LP`!Q98$ M!<0_Z-P11ID<&)P94/>""Q)W^1PFQ2W3C)3;M+>LNW3;VF5U]XD!#76W9_VS MEF9_M)VZHED]/ONH:>;&1#IV=O.4S_/><][_KWG/>=]?Q\-D]FDG)FE M.8OFY147S6)5? M?;,E@C7KI%>=:)OJ;QPYMKC2C:_K(72M-5JNM;'H%$UOH''$+@Y9: MVA("K'*=BT+$]+[7R0QI"PB MA+],RD::X#.2:B$=%<)W;P]C&B-FG$C"U@]"V6@-G_G<*!8V(`V$#&@&0O.> MD]"O[2#CH7>5I.?!^L;\E4^8RYP.N:JZ2BZ>[Z_*,DW$II2D%U:;[-^KI"&E MN)+T`JMI@]G^?5K:P%"HV>QH7K9\V8,IRV]5BB0E0TEZL<-L'SY`9`;:(DO2 MRVKLZRI,3KG*I"-):-M?L(^Q)>G5=MM*L\-H7F]QH-&JI\8[A+JSPEXC9-$D M&U62[C175J]'/79(?0/J<52/*$EWU*RD9GFP2JWQ5!V#Q(8QDM^E=;RC!M"HG#2]+75Z"2 M2A4M^HO:K%QU@4ZUFN'7+*?%9_LK&Z@E-]!-U/*"W42U(-"--EE$E?$X)J?) M[LQT.,UVFZ4<.[,NSE7M*1KFV&SED)623.>7%0C[0_IO)%W>=@C[F%R2GEU3 M66DQ!\][Z(;+23'&[X&DAP7\;0>&/I!`;]+P1-/2'H0'G4%V@ MS$9NL&RYU4IB;&:]U69;4U--)V%Q^F4;ALC6DZRS=0,-46NQ.QUE=K.YBII, M;.R).AB MD4.KR<>5(EE_)EO6GVQ/8+X'#1+WY!HDR5=AD$(\3H.D\;@-4JAOFT$*\SQ/ MI0Z#%-[4.@//D3$KMX!%E:2O,6]PFE9:S60^$PQEKG28G49QAG93E6-(F[OC MMXQW8MH/Q]#D8K,?CJ%WQAVK$XLZ$RN[-+(2`DOILYIZ-`K^;;S!\]25? MP6J=ZFH_'*,3?:/).'6R7@PU%Z.@S]"!T*2$-`ZP$!I@?X,P@-BV4$KN5C"6 M"Q:8O1F%EDT#^)%!&J^3:MUG7>QUSHZTIS*?I(=1PF$%WQB4/!,,DM:71;)Y M!`MA%,\*DM49I`A/DT$:Y=MAD$9__$PO8]Q$<[$RX1;E+`QHIE-@JU@,<#6; M#+0R>KJKV33@6C8#:&?S@0Y6#'2R9<"?HS=C#>C-V"_0@[%&MA[8PNJ`K:P9 MN(7]$KB5;0<^PUX";F>O`I]E)X$[F`^XDWT!?(Y%8$'/LZG`%]B#P#TL`[B; M90)?9B7`5U@I\$I'%^-4V$_F4"UW//FP<"!14_)@YCQ9UW]9(E]T9FSJ(PI2>JQ]T^'0DW`@<6A)P:&D M>,]*L_DIG$>*DN36"$=W/\9QC8KD.$R7HNC<>K>0+N&N/#F)'T'/#+A,BB*Y M]>W4LJ5=QSQAY+=1Y-IZ',RO6Z<,"P##0@0K)S>]`UMQ9W%^1*'58$>*I%R^ M^H%RU'M]RD]ZCEU3-#*D<4I/H)XM:Y3KRC5_U7M6!XD6*JE!%5HWY!@D6XX< M'.CBU3-G-/+I[E.18LEP;TVP\O$%5+4?]YP^K'IUJ1Q_^K"_+5CXV`NER*/M M,Y<['LN-"BPWC)9;=X+\B/R*IO!^ M*N7P#V@"UV/?0B@G',)8B8I$#@K%^$PNO!)[2^2]\+MX^)),IS;DW-$C#H,E M\D-IYS?>2;UHI.3NYBM16]Z[.3#0?PG@-]+!5BT+784`9&2K:`<&O&/*(?7* M]#1WUXS!;$G^E^CBW2XG=MU7HASR]DN77]I\J.%E?MW;<>*%NXXSA50=^0R44L6EP$C-WOGCJM M:0[>7OA"QK#Z+.'PL$IX^W1Q`J&><0;I#L\,@&\>A08KW2D%GN5YBAQM)[G< M"RC-;)U-,0&OOET-J103=6I`G8>038F'P\A&#TJ,+$JM%)J=<^VFZ@HC,Y.W M'H"QZ#Y?/07#9&`QL6O>B5.^46XT=T>Y]WR+AQH/2?].%+IRIS"V[Q]\:&#K M$V^NTMN7(9+=KO5S[N&B=;^(IQ."\4<(FPYD(Z8N74*Q5@H\P,J`!YD%^`[;$$HF MVPA\ES4`_\H:@Q7X.>L$7F2_!5YB7<`OV!^` M_\L.A)*Q^H#]C/*QJVU_8Q)'BIU97@X'*%LC5\7#+_`??@FUXJCT2#QMMS8F MU`HZ,ZXD?4Z.L4%LWJ%Y84>,LMZW#BQZ?4$O6 MH`G\ZH7^G!`MM%?*1]&29:NLMEC-A=5VB]/L'Q'_TZXI8Z:^CI^9D:W&FQ(L M9TEZM/7>H.]BNFQ,9Z3I%YK+D3IF6JUSK*;5,OS_4;K\:]&E\3JE,C47A+\L M[5W8-1[_[N/!.#I!E8OT#3D=BPLT].'BWI=\Y>+8T+.HSFGL:4"GIIMQ]>.3 MSV1L'@47S&K)'6BZ$5?_\<6OE&NJ+V^=BN>7;6Z@$887>Y.[>[=V4;X#EU\@ MDL5H$<+>4SY)/NYN0BXRX&F?PCP1!FF\9Q*Y[-T&2>])(?^N16KC:X1K+VU- M9`G"-NJ>@Y:]E2=9<)H.G//^CC<8GX($:!4E64H/14COA1CW;QC+H+Q+*]XX MC?>LUGLIAO>X-?\MHCNR"WY4TKT78_!`:_$F1J;]V3E).>6?%#-2EQLNS5[E MLGK!H;V+4HB'#=($3Q6!!_"KU@4!,C';&O`G!LPA3\+G,'W`!_B MKP'3>!_P8?X1@8,1;V6_.!>W>11?Z;EPI6<]R`4Z](^@B,$#E0Y%3C2 M3?XCW9\1?/]!!4:QQIZX)/\MPVF/0QK:="":"!;NA;@6&N4@70HE4M['`OQ! MJ#=^24ZH#N7>3Q>FZ?I`39@R0P2%1PBI^D@P:B1\[:)4G\UJ?X1YIL*/?$GT MXF<8)(//;)#N]#UAD*(]-H,TT8<8$>-K)0#SFN3;1;"'JB\CM'2WC@^$U,=M MM69_2&VB1V8=SL![35)"U`FOH2P"HY*E&0QAZ@K5A2E?-E^JT?5[:?NU!4AB MGOP=%>?HQ2OABA5I@2LDF,.Z<[DK2S.8TDX3[8\F?.6JTJBF\'ZE2SB9X;VD M2_OKQM?VT3N5<"3M_?J.M(,;V_?%4;4G[63]-HR24>#.&?B$>&<8[2^:C#'9 M(,7Z[J&=)I!L/@*AKXJJL,BDAUHGL>^/(IO)%Z:"35JZ:5;+)4)Q9J[1;N-` M)N\59\>_4@][A=ZU2">,TOAWL==Q_)HKMCUHI?YT/([@D*OZ1(*@@4_T;E5? MREE*'UZK))%H^5,!U!/QML0C.7GR/B00RJG;DJR48?54(@$G06 MI:C./ER!).4[0;B\5T^#<'EINJC.G@`M(VZBB^H\&*!E@UKZH!8_1+3,BD28 M,F3P!$3-"/>:,I/U9H28G*$6CGB+0Z12&IM$J\ M\'EO-+ MP%5\`%C!)\,,:_AC0"M?`ZSFU<"U?#UP'6\`/LG=P`:^#=C,.X";.7V`=?$_ M`5OYNT`W/PE\BG]"1N6?`[=P;01C;3P5N(WG`7_%*X`1Y&L;47#KU1B5HS+% M1$'X1F**T?^<*28-98K1MS/%'\038V_GB<\30ZPEAMA$/K2-O&DW,40\*I%M MM*/[1@78Y"!/C,,:Y/Z)*D],P=&F_G.>F%1_0K0)1P`W)+?QD[M$D+MXE?8I MQU2>"(9(2C2`EEI4:9`T)H[((*(#$6[E5;_WBBQQEMTB4;Z2>/(:[^- M-"8)TIB(4$(3)09)8Z)*&N,$:90%:=1!,58EC?3]0Q:D,19Y11P=X%#2:!4$ M4^;GTXX*TAA+(W5W&!G?-)K8'[''P\0>SZKL,9&V,(PIQ@]EBO$C,L5X/U-L M.C!+A+!-E+M,)/H63_3M9P![VQ'DXA/4G-JV>C4R7EM-53EEPQ;*+OQI]5RS M$\FN8U`\+B`NLI2M4>7B4]:]0EY<#;:G9LVW_XT`K[.%DI4?D"I2CD%Y^5QS ME=F.D7/*5YNS!9^,I\<>;S[=:>9\IA&.\K2XB3OXWX#;^07@LSP:OK"+9P/; M>2[P!9X'W,/7`O^3/PWT"'_Y-?\2^%_\,O!E?@7X%F_#D?R.=P!_SU\"=O'? MC*8T_0W@?GX(^$=^#/@G?@+X:L>]3&+!7T&Z^J\S8U&Q^/GKEHRNCCN8(*,# M_E_Q[]#3^ZV?;;_UBX=]3J\[HHJ' MI;<-)!XA$VYX3Y4/)T=/DGRDS_`MU##\4T(+_CC&=K8FL`CC*JNSQD&?YL<; MC1;ZCO!`ZD-&)N.!2$C$ MF03X"-"RFLG__G87(`E*3GHOT\KB8G>Q7]A=+'4X8+=*/HC2")8*GHB2X8/4 MBAT=G!Q'+-;%NI3+U++*L..CPY/#XU]^.6&#P[W=O5V@3L1"*F'80I?L]O+N M:OYO$=OAZ2KE=F^7,::T%WE])^3ZQGP_L%)NP%MX>_.?K^[N+I\>S>]O&%'CS\MW+\0 MY?W%V8?)-0C)C@+@]=6K"<+8<0N6[JW^>O0(%C@.E9N\GKZ=G%\@AT&IV,WW]&^E__*,/EER#LW^H0\;% M4&NN5[/I_TS8\Y^.CW[^^7E@"5AY?_4OD/K9<^+2/+]@F5[VYMR(9WW6\PR< M_P%-*BM4(A)6&3%BBTSKLO<'.V0-WHL7[`]V>MKP&S.;"F9$K%7"I&$+;JPH M73AY42YOWR$YZXAWO;V9@PB/:_"8%!O`?A&&/1V) ME]W<&`&9T+8**6K%>4>L[GV9J=@_YS@;"R4O!M@9X!\:9* MVAO`$+U^!#OK:ID>="R`1^3WVH8#;X_N\H=O+[^"M3>3&L='AK%<);Q,6A.Y MS")1O3;;3!Z+C"O2&>UI;%G%MBK%:&_7K@N!)][!V&>DJ)212R42EFG0]#%B MZQ$CB-HFGR&KU$*45F;R#]!)+)>PW*:A(=M:?!,LD@@UN%;7@QN-VZQ4 MKWBUV[0Z9*8JBFS-3"H+(JG7/$EWN#,GDO&A\P\1B+PKH3;E?:$P"7G1TB,@["K%X*<'^)U2O6 M62:Q[#;!N.!Q(LL1_D4WP'<0Q=7E@X-G)R=?B4@?/W7,-`9K(J/U^8C"5/$' MN:03\77BEPYU(4L0!:#B091K;QVWY`H[,#$1/8M'GA=@7MYJYO$-RSD9HQ!E MR@M0H"H5F!6(:HC2[9G,N3$C^FP/[%.JTZYU#P";YD5EG4!HE,NKFXGGXC/I M0*$2`V20"4/Y6*$,XG\K<#QP_@.<^=UW0-O#4QR0JGV+5%9KEND5$Q)]^/^U MO$U+#!RO1RK-EE5;NX5(FYED/M>/1B9B!%JHI4TI*\(S_IWK2B5TA/7C?\R> MN)I4BBP!I*HLP:#9FI4BYU+)9NW;SNAO;2<7->&O+\BTF/A4F/T2*=`(_\)3 MD_*B$,JPJ@#Y$L%MNI$93YM6IIL<3^MNIIL?3]F\%/S>8$^@F)TB._`@0YXV?5PW/W;P@\38PED/SQ-?HU.E`LVHK&+*?-GO9LM3\!!X*Z$N M?.7;FD2SE;1I'=I!_GS:%V%2W?"'CTFA1+E%^- M6I%<8OAZ-NF][(?)&&S-"ZVV=QFA\AE'=;#6.BT`U%1FO]!$Z*BV(CH]$3%\ MFDROLO68\C/LI- M)(51.WJ"\V::Y$LQ8NJ5#T3!3,I+,&$N*971>"#9;X9P1L\()8HDN;M3:!#!G/Y`(L8"N\_^_L.`^QP0K\9SO4:*A: M!X\E765S3]3X(16RI\M6\BI65,>`=B>* ME"JHIP3`X[+F+KP!VQ!UE:['3NQ;H`%'`^2[02F`#=%K[= M_E+GPS'K49("!'=H(S?V<)G%'=G^AK?)+PG/Z?A17!OY0'DR#HS=>I`<4WO" MXX/0/:TRNO%:$'_H^#&J*SL[V./K$G..FU(IO>J3V.[>$DCMRSI*Z_-OGZ9- MC/7JQI,K30VYUP&/P;Z_"^R[4(A/*!S1=W+L88^$&(*X#>I=RD MG8!!:'MJ&(9&AVH`#GG8)JN_TJ6QB:((E!T,>GH^/&W(^B_T?&]7+L!P\^]> M+&1IFOTP.*W!(0=>:G%KM-86/`X?D3PHQ^JX/7^ M$T'6(61O=[I@:UWMEX*F&+5_4*D([_^S5"YLKU]WZG$F>,FJPATIO#MH/V1L M]H]8#6I$C;KUVXOWZ>,G&CCBG@LG-A1KZ/DZB M1\P%AYZ/V&W=,M3;DIX%[(M"JGNL?;01*,#Q8,I<9AR;.J6H^V6-L8BTL>88 M)*5AT!N!DCL1>A@GN%LB+)<9-7MDLG97,.C.K].WKTYQ3,-I]/89MXB0\Q>0 MV::G`.(+@BY&J"64D;TP3K,VZGM'4-T\.!7EBA MF-$^Y>-5#CC('',"5]9=ZY!3*`DJ^04/;6/@\=YN,V-ZK4%T!>Q'-'?RN:#U MQ6>7-;9G2V.WL#%*\M!P3A0BNFM^Y&]'D6^F(KIPCI_:"2M!U-S[(JSG#=X3 M%1<7MHKNV"\$Y37"PEG#-XIE#>[4P!K8+2SC3LG8%B6H"!&K>3?)VNG1)M,- MX8/#'23)K^"%AP50OFSFY@OY(.II+&#.,(2#Y_C'FY^: M+V,?0B'OH%A32P4>\)V`Z)P`*F_N.L.SC`:WP;@8&VJ0*&)^[QK=39A--0\R M.HC?T89XM5+PI_9KYM#!!)8&,<%]B^;%Q(P.GSLP@5ENC2C'['`0%JVZ,7)S MO7W?5Q!MG/(2US&@QPSIFBYJ:S!*!!0[KBF_$X\8@K29Z]*-Q4Z(P"TR,'31 M/0[9^SZRP;(B+QXC^K,F1/RF2UZN`\.F.DM$&0@"2T`$GXZ&7FW\&>$BTYQ2 MR4RJC\].GG^B>O=:&WKPZ@@WO`(+&\S<*F&8&S.M[[$&X@W<,0LL#YJ!J39M MWR)L^)#%J8COO0O#Y%`SX8$F[7K-VFG4L3(FM=#$=;;SKSXZ+P=;PL49>3X413%>69H`H*K!B M)0""-VZ'`SK$7_'5BWKBW#L:/CLYZ;/_8C=_O[Z=W;R?OH;OKZ[/?INXKS=G MUV\G"*Z+9_V6I\5_=A*\IVQ(3\*7APT7=GST[,=`ONE^S@P*MA)XM]X''1<+ M72:$5TMM<&@)WE";)9:6`S0JE:^E[.'V6.[XUI;HU1 MX+V\.7DW$?'R($SCE)BI'SOD@K@?]\85#^(,N,2KV6LU[5R_Z\@@V-7 MMV6X^[SD]Y20<59#E1HYCIGPEY!L'8#](,.]2,1.F=A1^QJ\`<3,2VK0I7WH M=!H2OX6,65QJ8U(N2YKW>5GZ--<`9E87M3$,*&K%`6-3Q7B2T'NYJ!$>K1X, MZ.LWD30_<)Q2`7NT1G>C,M?L1E2`D%B)YO97#V?#16/MHFG3G5BPFQ_9XHB'%,6S';['RZO,2GR7X6QG1GX3LO0*F\SC MYZ[$;F_B-_"4[&AX?!*:9FM#T-:5:X=4TQT_'_[MV%]D-&R,RF9&1\&O*SJA M4\- M![Z9I'R'Z[#KBJ\W6ZFMW@)?]'DKN<'*O0`BU'YOUW,`_0MNW"2WJV>/&Z8+ M'(/1&HZ6#W.AJCX0M!T;9OZ]7;JM\OI2#3O7\\#F$K&HE*M/1:FM=L>#WNH? M^G[Y?'+W5MC?0,!>?PSB.>C9M($&]1*V09P'?+D(&%.LPF55V`VZ^C6B-?JE?O M](,4;MGGUG'(#LQY@^\4',:E>+2W1<)MP&9Z]T;_HQ*59W(^(?P+L;!=3HXN MM/E@5G=Y%])8;_[7`MW3K/P>(8^=IY8^./XD!?"_TM/A]W44=HH;=%-E1&D]^_^` MO*8/+RD@(S5W]5@C8-^9=WQ+BN8W,@'T6LR$2#H@1'3W-0+3A0?`EV(50$/D MMSSO,@74"[D0'7)T=(/8HE[-G76Z@G?,0:UCR/YJ?BWPARY=FA#C[]RD?\IW M0'/$#:H_XWSFU)9G,/@GXZ6#JF.^(Y]W1)>$IX` M4]03'%G21*'X1*<`3_E_\#4$L#!!0````(`#A35Q^@M):_ M$P<``/,Q```)````1D5!4TTN3T)*[=I_4!3G&<#Q=V]7..0B)P%$@X#1:/P1 M(R6QC:550$XM\0=R.42JYU4ATAA(\"Z:F,8C%R.PAF*-U-C0H,8T*29M^F." M<=(1+H.-EE',:$GIM*-!/&%BJAA-;>/U^QXX:L;P9_]@EIGG/KOW/OONNP_O MOCCCZXT4$46%KK6/3R4NU)J$6%VABEF[7JZUB"'.V>GV=$U^-.\(%\5O:"95 MF1MJL& M26)D33QMPV^TY3[I<945.I,5\9^:.)JB^IIR5WO+N6X90Z)Y3YGIBM7.*$"=NOF1^Z5.%?9>43Q1'*S0Q M:[>RM;Y35:+%>L<#T?Y)0K02?R5.$?+'J_"AHH9A&(X1.!0M>`=&H15Y&N^= M&(N,1_`@7BHJ[L($3,0D'(-WXSB\!R?@O<@]O9/Q/IR*TS`%4_$!G([?QH=P M!J;A]W`FSL(,S,0LM.%MQ-^[!O?@&OHE,0]&`^_`=_`V^B[_#/^`? M\3ULQ/?Q`'Z`?\*#V(1^_!!;\!!^A(?Q+]B*1_$8'L>/\02>Q';\!#OP[_@/ M_">>PM/8B6?P+`:P&WOP,SR/_\(+V(N7\#)>P7_C5?PO?H5!%$Q4DR*\*@[! M,#1C!$:B!8=A%`[':(S!6!R!\3@*[\+1F(B\V]XQ.!;'X7B<@!-Q$D[!^_!^ MG(;?PE1\$*?C=_`A_"ZFX?=Q)J9C!L[&+)R#<_$'F(WS<0$NPAS,13LZ,`_S M<2G^$)>A$U?@CW`E%F(1KL9B?$P1U77#1:=F-W6:"0MAM9LRZAN%7(?K\1G<@#_!YY!UP5N./GP!7\3-6(E5N`5?PI]B#?X,M^%V MK,4=^`K^`E_%7^)KN`MWX^NX%W^%;^*OL0'?QG<4D5+?*ECH%^?D[G]PP5)E M%RN/N'(J:M\QZRR]O?]@C_PR:M_'5MU?D+_4WVKU[Y&+6&6L67ZR,E/@W)RP MU(ZB+4<:Y7+6FE*TI:/ZX/Z/Y*L^OG)DN-[>J(2^SR]8XL@CMS&"9:AU3-&6 M(=90'RR`(ER72Y!(/;@_64[5AL8(EK3WC\CE;EA2ZYBD_`+G"T!)F6X&M)[JND43VC>M^8EB+7;KEN3^'% MGT$4VY7:^H!J>ELS"FM,2Z-Z@[MZ=?5G5=-6LU%$8PH:U1O4U7M,_E%W6XPB M&E/0J-[@KMXG\E5?8A31F()&]09Y]<[)5STMQBBB,06-Z@WNZG76GU%-R?%& M$8TI:%1O$%?OD'S/E02CB,84-*HWB*MW4O[3_722441C"AK5&]S5NRK_EZUE MK%%$8PH:U1O4U=M:OULUO37!*.+_:0JR_=&1E\,.P8N-?V8+X?Y%/R"WF%[IK8P+-%P_3Y;G#BVPDR_N"095 M46DS-P6&^0Y:*VT67XMUGL??W]\CW*R73A/U$HU^S[71K^[0]+"F;FM3P*IJ MV^5>QA8M7/#KN-(3]7JS58U[.J&\6=XT,.-V_9=?E6UE">7=H9RXV^54QLGN M/@MUY]#Z^DM6`MTGOJ&_Y/[^R&FY74ZE'#+COF74NL-2$1,N'S=JT[W!8'#9 M3<^ M;=';?$VJ[[3:=,X4'+==;MO7<[74CD<_7=F3$#KR?:[VI/YT!^P7(G0^J;*#S1 MRNM/5%D7*\YLLRMGOK(K7;\G_F97SL;9E2^JV/;K_A]02P,$%`````@`/%97 M'Z3V7-D``0``K0$```0```!&12Y(;9!-3L,P$(77B90+L++4!6E4T0.P:YL` M0I2%$PF$4-3:DV0HV);M@')[Q@W]`>&5YWWSQL\SG[-;L'#IF.^`%3DS5GOM M!P/N*HDGV"@)#5OE15WD5%.!"HYU$G]JE&2K[Q3Z5'0;RS*A58/M]/H$>==[ MJ;]4>BX&!Q<68)1'+^E+_6'P';BQZ.%GI-.]%1#:4/F]V=W#,,(=#&?@!CP1 ME_Z62A2[H$41_;=R8#_T,K(#66HUO7C]@V$9UF:\7[KZ*JM MF[ZLJP=>+?CKC`7#$I0'2YSO^=,LB2,Z_Z#GD.ZTB1+<87>N0S-.VR@*-O9- M0$ELDOCB&U!+`P04````"``U4U````"````$U!2T5&24Q% M*RC*STI-+E&P4DBUBDDMR\PI+;EX MN10S\Y)S2E-2\>C)S3;DY9("`%!+`P04````"``35US6;#0; MY.0&HP3%B1[<\J1(<0"6D`$O6-*-LTQ/6(5<<3$@[W&Q`#>B4D=MGFT%7:XD MG/?[E^`)?H^QA#O.8-KNZB4.YK&@F:2<#:",P/.YC5*G)O\`/FYHKO!4)^8B MT=0J1IQ((M'&B;V*V!)S-6&:9OF8I'J;5=-[>MT>N7ACG/>,_B6Y7Z<`))>1 MD`=G&MHPF=KNW!D%@[K07E(6IT6"=EP MFCQBM'99VZKS&E)>IE4Y3Z'9^-EL$%J!L6(-)O2N])^5+J"EN5Y!:/G7H]"; MV*=0KB;5TD[GBJAF&!!&8HE28G)4SCZHEUIQ]DY95E^EJ$<+$:TQ_USM_7*E M-SJXB(I4EB5@G&'W2=H;?Q[\F?8OHA>=G>P.8$]FZ%L?1I5*1;O"7-5?50-_ MQ&F1J[(?_5O^+73@:8*'FN^+ET;;\4U"`P``604` M``P```!!4E133U5.1"Y/0DI]5$ULTV88?IW8:=IFD*H98H,N"(+:2575%;9U MB,G-XG:I%.J`G;I3VF7Y\4A0$F?VY])>IAS=54CK8=7&-+$)(7Z.7.&"$!65 M4*\<."/!D4LODYJ]KY/TGUU>^?GYOO?G^S[7P]`W?F%V?'HRD5(GY=FD'/M\ M-FLRR["KA:%\K19W_%!_("LC(\-!IP/J?Y[[4:YM.9U0WY(XB"63Z\X9J+]] M,ZV%3QS8R*Z6YG73TH>*_SI]Z.I7M?"'!]-90\6KSEG4>S4M_/_EO'.\Z`NL MG@;@8[(TSDM1->K]1E'XB414]4G?7I%322&CCL^H]A^=4/H*`#H\W$-'P()E M[LYJ!P@Q>4I17Z)Z'T7P>[G[JW[PN>S([3;=Z>7ND3E#"5ZWV2XO=W?5!WP& M,WY$)%L7H)OG\C>[P-?P-+P-OB$D;GIPW4X!, MQS0Q9>GF_@T"8Z@%-#%OF]>+61:I9H/$""LOL(\>3:R91DZW,OI"R4*Q'"+Q MB&MG1=-VN>/$=6DBTRNU!<0G=^%%Q*<(=VJB9>=(CNQ`4@<(?H#%36644I4: MR`WN4#'#:E(24L?=O$;NVOXF!N/-!MDAVC!I1]QCZ7;7UTIY3'N>Z`Y-7"@B M&"7@Q_4NNAAO%LB:<*SE+%#Q4@LLDA)O+W-18GN9"Y/M9=2D2J`7CXGAK8Y: M3#>-4@$[*\_$F_-TA0G#*"`W2URPQ27=^2/[`[%S_XC`T6DJEZ<_>[6YQC/A M$>$;@;^(Y9XL_\0O#6^N<4Q8G@PL^3?7/,RWK/X>6@I^_UWZQA@\W5C1P,/U M:6)4R2@Z2](P!G!B.!5FFWHD4OYTWKV?H::E:%R_9,R7='2A,DI*CZO0O9R8 MV44?^TW$"MQ/N`!>C!=!P/@U=&$4X2C&,>C#&`5\QQ"#?HP2#&*<@!&,&RM_ MXREA;9)=J93T[=N\^S@+-(:/6^^+?#C>/?ISS'FB_;8.,3PFP\GM=W6((X2/ MFYIL7O"\09<\/5#J+QX`]A]02P$" M%``4````"`!,5UZ3$/`(``!&$0``"@`````````!`"``````````3D5% M1$5$+E185%!+`0(4`!0````(``!75Q]:CY0>=`$```H%```,``````````$` M(````!@)``!%5DE,551)3RY-2S%02P$"%``4````"``G5%AH*AY2`!```$`P``!P`````````!`"````"M'0``1D5!4TTN2%!+ M`0(4`!0````(`*]65Q^LJA.271(``)LZ```*``````````$`(````/(>``!& M14U!24XN0U!04$L!`A0`%`````@`ZU97'WA?27K9$```1QT```H````````` M```@````=S$``$9%34%)3BY/0DI02P$"%``4````"`#H5EP/``!6 M*0``"@`````````!`"````!X0@``54Y)5D524T4N2%!+`0(4`!0````(`#A3 M5Q^@M):_$P<``/,Q```)````````````(````(Q2``!&14%332Y/0DI02P$" M%``4````"``\5E;0````%X````(``````````$`(````.A: M``!-04M%1DE,15!+`0(4`!0````(`!-75Q^L,'J+(`(``*`)```,```````` M``$`(````$Y;``!!4E133U5.1"Y#4%!02P$"%``4````"``45U Received: from dub-img-2.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t7n2s-000fJbC; Tue, 24 Oct 95 10:21 PDT Received: by dub-img-2.compuserve.com (8.6.10/5.950515) id NAA27461; Tue, 24 Oct 1995 13:16:10 -0400 Date: 24 Oct 95 13:00:52 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Directors Subject: Universe code Message-ID: <951024170051_71044.2164_GHI197-4@CompuServe.COM> > poc5 (Even numbers seem to never go anywhere :>) is appended. It >is not functioning as I lack the v5 of Universe code to get it going. You didn't get the copy that I posted to the AG-Directors list? Something must have gone wrong with my post...here's a repost of universe.c 0.51: /* Universe code version 0.51, copyright us 10/5/1995 */ #include "universe.h" /* ** Renamed (more meaningfull and also Capitalized for important arrays): ** objects -> Live_Objects ** spares -> Spare_Objects ** sector -> Sectors ** thrustcost ->ThrustCost ** ** *_Objects are all gone now (Sic Transit Gloria Mundi) instead we ** now do all list access *through* the dummy object, e.g. ** Live_Dummy.next_ob is the first live object. ** We could have MACRO's defined for these but do we really need ** them ? */ /* ** Inserts an UN_Object into the specified object list (which ** means Live_Objects, Spare_Objects or Player_Objects at the moment). ** ** Now that this is doubly linked and we have dummies, we no longer need ** pointers to the lists and can access them through the dummies ** themselves . ** ** Assumes that the UN_Object was correctly removed from any ** previous list it belonged to. */ void UN_ObInsert(UN_Object *ob, UN_Object *dummy) { ob->prev_ob = dummy; ob->next_ob = dummy->next_ob; dummy->next_ob->prev_ob = ob; dummy->next_ob = ob; } /*-------------------------------------------------------------------------*/ /* ** Removes an UN_Object from whatever object list it belongs to. ** ** Will probably crash if the UN_Object wasn't in one. */ void UN_ObRemove(UN_Object *ob) { (ob->next_ob)->prev_ob = ob->prev_ob; (ob->prev_ob)->next_ob = ob->next_ob; } /*-------------------------------------------------------------------------*/ /* ** Next two routines are exactly like previous two but act on sector ** lists. */ void UN_HashInsert(UN_Object *ob, UN_Object **list) { ob->prev_hash = list; ob->next_hash = *list; (*list)->prev_hash = &(ob->next_hash); *list = ob; } /*-------------------------------------------------------------------------*/ void UN_HashRemove(UN_Object *ob) { (ob->next_hash)->prev_hash = ob->prev_hash; *(ob->prev_hash) = ob->next_hash; } /*-------------------------------------------------------------------------*/ /* ** Move an UN_Object from one sector list to another. */ void UN_Shift(long sectx, long secty, UN_Object * obj) { /* first remove us from our old list */ UN_HashRemove(obj); /* now insert us at the start of the new list */ UN_HashInsert(obj, &(Sectors[sectx][secty])); } /*-------------------------------------------------------------------------*/ /* initialize starting UN_Objects (as in, we *know* that we'll need at least ** STARTOBJECTS UN_Objects, so let's allocate them while the user expects ** initialization lag) */ /* ** I'm assuming that this gets called exactly once. ** ** That's the current plan. */ void UN_InitTable() { int i,j; Live_Dummy.prev_ob = &Live_Dummy; /* make a closed doubly-linked list */ Live_Dummy.next_ob = &Live_Dummy; /* with one member */ Spare_Dummy.prev_ob = &Spare_Dummy; /* ditto */ Spare_Dummy.next_ob = &Spare_Dummy; Player_Dummy.prev_ob = &Player_Dummy; /* ditto */ Player_Dummy.next_ob = &Player_Dummy; /* ** The following leaves undefined UN_Objects in the Spare_Objects list, ** UN_InitSector will initialise and move them to Live_Objects ** as things are created. */ tobj = (UN_Object *)malloc(sizeof(UN_Object) * STARTOBJECTS); for (i = 1; i < STARTOBJECTS; i++) { UN_ObInsert(tobj++, &Spare_Objects); } /* now to initialize UN_sin[] and UN_cos[] lookup tables */ for (i = 0; i < 255; i++) { UN_sin[i] = sin(i * 360 / 256); /* or does the libm sin function */ UN_cos[i] = cos(i * 360 / 256); /* expect angles in radians ? */ /* It seems that strict ANSI C sin() and cos() do expect angles in radians... ** we'll have to change this after confirming that the compilers we're using ** expect radians and not degrees. */ } } /*-------------------------------------------------------------------------*/ /* used to insert a new UN_Object into the ** objects list and its Sectors[][] list; assumes that nothing critical is ** being pointed to only by obj->prev_hash, obj->next_hash, obj->next_ob, or ** obj->prev_ob ** ** Note: I've updated this function but the things it does don't ** make a lot of sense 'cos the UN_Objects list and sectors lists ** aren't likely to be adjusted at the same time now ** we have Spare_Objects. */ void UN_InsertObject(long sectx, long secty, UN_Object *obj) { UN_ObInsert(obj, &Live_Objects); UN_HashInsert(obj, &(Sectors[sectx][secty])); } /*-------------------------------------------------------------------------*/ /* ** Returns an UN_Object (e.g. for alife creation, missiles appearing, ** explosions ...). Note that nothing can be assumed about the initial ** values of any of the UN_Objects' variables, especially next_ob and ** prev_ob ! */ UN_Object *UN_CreateObject() { if (Spare_Dummy.next_ob != &Spare_Dummy) { return (UN_Object *)malloc(sizeof(UN_Object)); /* What no check ? */ /* No check for now, since debugging won't use very many objects, but a check ** should eventually be inserted here. */ } else { UN_Object *tob = Spare_Dummy.next_ob; UN_ObRemove(tob); return tob; } } /*-------------------------------------------------------------------------*/ void UN_DeleteObject(UN_Object * obj) { /* Removes an object in the Live_Objects list from that list and its ** Sectors[][] list. */ UN_ObRemove(obj); UN_HashRemove(obj); UN_ObInsert(obj, &Spare_Dummy); } /*-------------------------------------------------------------------------*/ /* UN_CheckObject is called for each object each 'tick' */ void UN_CheckObject(UN_Object * obj) { curwhat = obj->what; /* type of UN_Object stored in curwhat */ curpic = 0; switch (curwhat) { /* get keys & virtual keys */ case PLAYER: /* this is the player */ obj->extra.animate.actions = FE_GetKeys(); /* get the real keypresses */ break; /* <<1>> */ case PROBE: /* this is a probe */ probes_exist++; /* count surviving probes */ /* get the virtual keypresses from a short AI routine - ** real alife work is done elsewhere */ obj->extra.animate.actions = AI_GetKeys(obj); break; /* case missile (probe remote control, and standard control routines) */ /* case SUPPLY */ } /* end of switch(curwhat) */ if (curwhat <= MISSILE) { /* this is an animate UN_Object */ UN_Animate(obj); } /* end if animate */ /* Note that curpic is set in the code that was move to UN_Animate(); ** it might be clearer to move all curpic setting code in that function ** (which for now consists of detecting thrusting and braking) back into ** this function. */ if (User->extra.animate.target == obj) { curpic |= TARGETPIC; } AS_SetPic(obj->pic, curpic | obj->facdir); /* <<2>> */ UN_Movement(obj); /* Movement update */ } /* ** <<1>> this makes all objects of type PLAYER act in exactly the same ** way...we might want to have some other means of controlling PLAYER ** objects that aren't currently being controlled by the player. */ /* ** <<2>> Sets the current picture so FE can just display it if it is visible, ** also allows cycling of colors. We may want to move this to after the ** collision detection. ** ** Do you mean "&" in the previous ? Isn't "|" more likely ? ** ** No, I meant to use "|", since "&" would set the parameter to 0. ** ** Also, "(facdir + 256) % 256" could be avoided if facdir was an unsigned ** char which must remain in 0 - 255 with automatic {und,ov}erflow ?? ** ** Elsewhere in the code facdir was assumed to be +ve so I scrapped the ** previous bit. */ /*-------------------------------------------------------------------------*/ void UN_Animate(UN_Object *obj) { tempx = obj->x / SUBSIZE; /* store original subsector */ tempy = obj->y / SUBSIZE; if (obj->extra.animate.actions & THRUST) { /* forward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx += (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely += (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ curpic = THRUSTPIC; } else { /* not enough energy for thrust */ /* FE call here for thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, THRUST_FAIL); /* <> */ } } /* end of not enough energy code */ } /* end of THRUST code */ else if (obj->extra.animate.actions & BRAKE) { /* backward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx -= (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely -= (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this brake thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ curpic = BRAKEPIC; } else { /* not enough energy for brake thrust */ /* FE call here for brake thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, BRAKE_FAIL); /* "hardware" interrupt */ } } /* end of not enough energy code */ } /* end of BRAKE code - end of THRUST/BRAKE code */ /* * NOTE: we might want to kick out different turn speeds, and use a * standard turnspeed instead for each object */ if (obj->extra.animate.actions & LEFT) { /* turn to the left */ /* <> */ obj->facdir = (obj->facdir - obj->extra.animate.turn) & 0xff; /* <> */ } /* end of LEFT code */ else if (obj->extra.animate.actions & RIGHT) { /* turn to the right */ /* turning to the right, so clockwise, means increasing angle */ obj->facdir = (obj->facdir + obj->extra.animate.turn) & 0xff; } /* end of RIGHT code */ /* <> */ /* ** New target code, it's simpler. ** However, this has an important feature that the objects will ** always come up in the same order (which wasn't true for ** Adrian's hash-by-hash version). ** ** Still needs work, though. Won't hang if the previous target ** has moved out of range and there are no other targets, but only because ** you can target yourself :->. */ if (curwhat == PLAYER) { if (obj->extra.animate.actions & NEXTTARGET) { /* cycle to next target */ do { do { obj->extra.animate.target = obj->extra.animate.target->next_ob; } while (ABS(obj->extra.animate.target->x - obj->x) > 5 || ABS(obj->extra.animate.target->y - obj->y) < 5); } while (obj->extra.animate.target != &Live_Dummy); } else if (obj->extra.animate.actions & LASTTARGET) { /* cycle to previous target */ do { do { obj->extra.animate.target = obj->extra.animate.target->next_ob; } while (ABS(obj->extra.animate.target->x - obj->x) > 5 || ABS(obj->extra.animate.target->y - obj->y) < 5); } while (obj->extra.animate.target != &Live_Dummy); } } /* Minor problems with the targetting code: ** #1: Comparing x and y will compare the universe coordinates, in which 5 ** is a very small distance. Better to compare x >> SUBPOWER and ** y >> SUBPOWER. ** #2: This cycles targetting the same way whether obj specified to target ** the previous target or the next target; those two actions are ** supposed to cycle the current target in different directions. ** #3: Can only select targets in the same row as the player (large x ** and small y differences are the only ones accepted...both comparisons ** should use < or <=; neither should use > or >= if an object can ** target itself). */ /* need to add in FIRE for PLAYER/PROBE */ /* need to add in cycle weapon code for PLAYER/PROBE */ /* one possibility: have objects outside of the objects list be the prototypes for each weapon, with next_hash/prev_hash forming a circular double-linked list for each object; cycle weapon would then get the next (or previous) object on that list, while fire would merely make a duplicate of that weapon into the objects list, editing velocity, position, and (if needed) target as needed */ /* need to add in energy to shield code for PLAYER/PROBE/SUPPLY */ /* need to add in breed stuff */ /* need to add in pick up/drop */ /* these last two could merely set flags (for instance, object->extra.animate.actions & BREED) that could be checked if the object bumps into another object, since fertilization and grabbing will only be processed when an object that is trying to do that comes into contact with another one */ } /* ** <> assuming navigation system with north = 0, clockwise increase ** calculate vector changes */ /* ** <> hardware interrupt for AI, note that hardware interrupt calls ** don't do anything directly; the interrupt is just registered, ** later the interrupt handler will handle it */ /* <> turning to left, so counterclockwise, means decreasing angle ** ** % operator doesn't work here, because when turning left the facdir ** will never rise above 255. Instead code is needed to handle facdir ** < 0. This code will break with turnspeed > 256 :) ** ** I've changed it to use "&" which should work on all 2's compliment ** systems (which I *think* is ANSI for C). ** ** Although it is widely used, 2's compliment is apparently not ANSI C. ** There is a good chance that all of the systems we write this for will ** be 2's compliment, however, so maybe we should check with FE before ** changing this just in case we don't have to. */ /* ** <> code and comments removed ** if (obj->facdir < 0) { ** obj->facdir += 256; ** } ** ** alternatively (if faster?) use: obj->facdir = (256 + (obj->facdir - ** obj->extra.animate.turn)) % 256 */ /* ** <> excised entire target code and rewrote . ** ** ** target code for player only...probes handle this differently, and ** this only allows the player to target things in the 11*11 ** subsectors nearest to the subsector that the player is in, since ** this is what will be on the player's screen...and while we could ** allow the player to target anything, the player will probably not ** want to spend the time to cycle through everything that's out of ** sight to target an incoming food source ** ** ** note: this has bugs in it (especially the "last target" part), * so ** IGNORE the target code for now. ** ** if (obj->extra.animate.actions & NEXTTARGET) { ** cycle to next target ** ** if ((obj->extra.animate.target)->next_hash != NULL) ** obj->extra.animate.target = ** (obj->extra.animate.target)->next_hash; ** else { ** search through sectors to find a target ** ** long x = ((obj->extra.animate.target)->x / SUBSIZE), y = ((obj->extra.animate.target)->y / SUBSIZE); ** x++; ** if (x > tempx + 5) { ** x = tempx - 5; ** y++; ** } ** if (y > tempy + 5) ** y = tempy - 5; ** while (Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS] == NULL) { ** x++; ** if (x > tempx + 5) { ** x = x - 11; ** y++; ** if (y > tempy + 5) ** y = y - 11; ** } ** } ** obj->extra.animate.target = ** Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS]; ** } ** } ** sorry for the tab shifts above, but I don't know if I can break up the ** Sectors[formula][formula] without inducing a parsing error ** ** end of "next target" code ** ** else if (obj->extra.animate.actions & LASTTARGET) { ** find previous target ** ** object *tar = obj->extra.animate.target; ** if (tar->prev_hash != ** &(Sectors[tar->x >> SUBPOWER][tar->y >> SUBPOWER])) ** obj->extra.animate.target = *(tar->prev_hash); ** else { ** cycle through sectors to find previous ** * target ** ** long x = (tar->x >> SUBPOWER), y = (tar->y >> SUBPOWER); ** x--; ** if (x < tempx - 5) { ** x = tempx + 5; ** y--; ** } ** if (y < tempy - 5) ** y = tempy + 5; ** while (Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS] == NULL) { ** x--; ** if (x < tempx - 5) { ** x = x + 11; ** y--; ** if (y < tempy - 5) ** y = y + 11; ** } ** } ** obj->extra.animate.target = ** Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS]; ** } ** } ** end of "last target" code; also end of player's "change target" code ** ** */ /*-------------------------------------------------------------------------*/ short UN_NewLife() { /* Called when the player's probe has just died. This routine determines if the player has any "lives" left. If so, it turns one of the player's "life" objects into the player object, sets whatever variables are needed for it to be the player, then returns 0. If the player is out of lives, it returns 1, which the main play loop takes as a signal to end the game. No parameters should be needed, since the object and subsector lists are global. */ if (Player_Dummy.prev_ob == &(Player_Dummy)) return 1; else { UN_CreatePlayer(User->x,User->y); /* default initial placement */ return 0; } } /*--------------------------------------------------------------------------*/ /* ** needs: UN_ReSeed(), ** No, I don't think so re-seeding is different, when re-seeding ** (if I understand it and if we really want it) there's a whole load of ** stuff that may be already set up. Whereas here, we have to do it all. ** ** I put that in because I thought that UN_InitSector() would call ** UN_ReSeed() to actually do the object creation. */ /* ** This was the brief: ** ** Initializes a sector (including "dummy" objects at the end of subsector ** lists), populates it with food sources, asteroids, and probes of the ** appropriate level, then places the player (object #0, genotype #0) ** somewhere in the sector. Also does anything else that is needed at the ** start of a sector. I do not know what parameters will be needed; ** you will have to determine what info is needed. ** ** Comments: */ void UN_InitSector() { /* ** Tidy Object lists by just dumping any Live_Objects onto ** Spare_Objects. (This leaves inactive Player_Objects untouched.) */ while((tobj = Live_Dummy.next_ob) != &Live_Dummy) { UN_ObRemove(tobj); UN_ObInsert(tobj, &Spare_Dummy); } /* This could be done as a single transfer but I'm too tired */ /* ** Just blank the hash tables. */ for(i = 0; i < NUMSUBS; i++) { for(j = 0; j < NUMSUBS; j++) { Sectors[i][j] = &(Dummies[i][j]); Dummies[i][j].prev_hash = &(Sectors[i][j]); Dummies[i][j].next_hash = &(Dummies[i][j]); /* next_hash shouldn't ever be referenced but this may be safer */ } } UN_CreatePlayer(0,0); /* As good a place as any to start :) */ for(i = 0; i < StartAsteroids; i++) { UN_CreateAsteroid(); } for(i = 0; i < StartFood; i++) { UN_CreateFood(); } for(i = 0; i < StartProbes; i++) { UN_CreateProbe(); /* This isn't the only place a genome could come from. This is where 'seed' ** genomes arise (from the archive of previous heroes ? (In which case the ** archiving routines might eventually fall into a different function heading ** AR_* ?)). */ /* True, however, UN_CreateProbe() will always need to have a genome for ** the created probe, so I've moved the genome creation call to inside the ** UN_CreateProbe() routine. */ } /* ** ... ** Insert any other object type you want to start with here. */ } /* ** Pulls a player object off the waiting stack (Player_Dummy) and sets it up ** as the active player. If there aren't any on the stack, behaviour ** is undefined (might ultimately create a default one but I don't yet ** know enough to say what 'default' is). ** ** Default: this procedure should not be called if ** Player_Dummy.prev_ob == &(Player_Dummy). */ void UN_CreatePlayer(int x, int y) { User = Player_Dummy.prev_ob; /* Use last craft from list (e.g. FIFO) ** as new ones will be added to front. */ User->x = x; User->y = y; User->velx = 0; User->vely = 0; User->facdir = 0; User->target = User; User->genome = (genotype*)NULL; User->action = 0; /* ** presumeably all other properties are set-up by whatever process ** generates the members of Player_Objects . ** ** Possible exceptions, shield and energy (always start 'full' ?). */ UN_ObRemove(User); UN_ObInsert(User, &Live_Dummy); UN_HashInsert(User, x >> SUBPOWER, y >> SUBPOWER); AL_InitPlayerGenome(User); } /* ** Creates an asteroid. */ void UN_CreateAsteroid() { UN_Object *temp; temp = UN_CreateObject(); temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * AsteroidVelocity) - AsteroidVelocity; temp->vely = UN_Random(2 * AsteroidVelocity) - AsteroidVelocity; temp->facdir = UN_Random(256); temp->target = temp; temp->genome = (genotype*)NULL; temp->action = 0; /* ** presumeably all other properties are set-up by whatever process ** generates the members of Player_Objects . ** ** Except for the fact that these aren't Player_Objects. ** ** Possible exceptions, shield and energy (always start 'full' ?). */ UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, temp->x >> SUBPOWER, temp->y >> SUBPOWER); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER); } AL_InitAsteroidGenome(temp); } /* ** Creates food (I can't remember what food is like so I'll skip this) . ** ** How long has it been since you've eaten? :) */ void UN_CreateFood() { } /* ** Creates a probe (without genome). */ void UN_CreateProbe() { Object *temp; temp = UN_CreateObject(); temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * ProbeVelocity) - ProbeVelocity; temp->vely = UN_Random(2 * ProbeVelocity) - ProbeVelocity; temp->facdir = UN_Random(256); temp->target = User; /* (:-> */ temp->genome = (genotype*)NULL; temp->action = 0; /* ** presumeably all other properties are set-up by the addition ** of the genome . */ UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, temp->x >> SUBPOWER, temp->y >> SUBPOWER); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER); } AL_InitProbeGenome(&temp); } int UN_Collision(UN_Object *which) { /* Need the appropriate parts of movement moving in here. ** Might need two versions of this, one for set up and one for ** play but I think one will crack it. */ /* TO BE WRITTEN */ /* Returns 1 if the newly created object passed as a parameter overlaps ** any other object currently in play; returns 0 otherwise. */ /* For now, just returns 0, so new objects might appear in the middle of ** old ones. */ return 0; } /*-------------------------------------------------------------------------*/ void UN_Movement(UN_Object *obj) { obj->x += obj->velx; obj->y += obj->vely; /* <> */ subx = obj->x >> SUBPOWER; suby = obj->y >> SUBPOWER; /* did this UN_Object move into a different subsector? */ if ((subx != tempx) || (suby != tempy)) UN_Shift(subx, suby, obj); /* update sector lists */ /* <> */ xh = ((obj->x - SUBSIZE + 1) >> SUBPOWER); yh = ((obj->y - SUBSIZE + 1) >> SUBPOWER); /* This is to get the left and below squares ? , ** (subx - 1) & 0xQQQQ might be quicker. */ /* It might be, but then we'd have to re-compute the sector number if ** obj->x or obj->y < (SUBSIZE-1) when we checked the object's current ** sector. */ for (txh = xh; txh < xh + 2; txh++) { for (tyh = yh; tyh < yh + 2; tyh++) { ttxh = (txh + NUMSUBS) % NUMSUBS; ttyh = (tyh + NUMSUBS) % NUMSUBS; /* Not sure we need the "+ NUMSUBS" 'cos xh & txh are now always +ve */ /* xh and txh can be negative if obj->x < (SUBSIZE-1). */ this_obj = Sectors[ttxh][ttyh]; while (this_obj != NULL) { if ((this_obj == obj) || (this_obj->shield <= 0)) continue; /* Can't collide with yourself, and a bullet's explosion can only hit one ** other object per object that the bullet contained. */ /* Bullets have shields < 0 after one collision ? */ /* Bullets' shields are set to 0 upon collision since they're supposed to ** die after one collision anyway... */ if (ttxh == txh) dx = obj->x - this_obj->x; else if (ttxh < txh) dx = obj->x - this_obj->x - (MAX_X); else dx = (MAX_X) + obj->x - this_obj->x; if (dx<0) dx*=(-1); if (ttyh == tyh) dy = obj->y - this_obj->y; else if (ttyh < tyh) dy = obj->y - this_obj->y - (MAX_Y); else dy = (MAX_Y) + obj->y - this_obj->y; if (dy<0) dy*=(-1); /* previous section can probably be made simpler if we also re-do ** the following if statement, 'cos only one term of the boolean will ** apply to each conditional above. */ if (((dx < this_obj->bboxside) || (dx < obj->bboxside)) && ((dy < this_obj->bboxside) || (dy < obj->bboxside)) && ((dx * dx) + (dy * dy) < (((this_obj->bboxside + obj->bboxside) >> 1) ** 2))) { /* <> !!! */ /* we have a collision between obj and this_obj, so handle it */ if ((this_obj->what == BULLET) || (this_obj->what == MISSILE) || (obj->what == BULLET) || (obj->what == MISSILE)) { if ((obj->what == BULLET) || (obj->what == MISSILE)) { this_obj->shield -= obj->extra.bullet.damage; obj->shield = 0; AS_SetPic(obj->pic, EXPLODE); if (this_obj->shield <= 0) AS_SetPic(this_obj->pic, EXPLODE); } if ((this_obj->what == BULLET) || (this_obj->what == MISSILE)) { obj->shield -= this_obj->extra.bullet.damage; this_obj->shield = 0; AS_SetPic(this_obj->pic, EXPLODE); if (obj->shield <= 0) AS_SetPic(obj->pic, EXPLODE); } } else if (obj->what <= SUPPLY) && (obj->extra.animate.target == this_obj) { /* code to handle breeding, grabbing, etc. */ } else if (this_obj->what <= SUPPLY) && (this_obj->extra.animate.target == obj) { /* same code with this_obj and obj reversed */ /* not necessary surely 'cos it'll get called in reverse ** when this_obj is itself collision detected. */ /* After the "generic collision" code below is called on this pass, which ** is not necessarily desirable...especially if we implement collision ** damage at M4. Plus, if this_obj is going fast enough, it might fly ** over obj entirely on its next movement check, which means no collision. ** */ } else if (this_obj->what == STICKY) &&(obj->what == STICKY) { /* merge two sticky bricks into one object */ } else { /* objects bounce off of each other */ tempx = obj->velx * obj->mass; tempy = obj->vely * obj->mass; /* <> */ obj->velx = (this_obj->velx * this_obj->mass) / obj->mass; obj->vely = (this_obj->vely * this_obj->mass) / obj->mass; this_obj->velx = tempx / this_obj->mass; this_obj->vely = tempy / this_obj->mass; } } this_obj = this_obj->next_hash; } } } } /* <> ** if (obj->velx >= 0) ** obj->x += obj->velx; ** else ** obj->x -= (-1) * (obj->velx); ** ** if (obj->vely >= 0) ** obj->y += obj->vely; ** else ** obj->y -= (-1) * (obj->vely); ** ** I didn't get the previous two if's at all ! ** Isn't "- (-1) * x", identical to "+ x" ? ** remember that unsigned numbers underflow happily as well as overflow. ** (I may be wrong but I'd be suprised) ** ** torrodial space needs no implementation: overflow and underflow should ** take care of this for us */ /* <> ** detect collisions ** ** moved the next comment from inside the loops so I can read it ** ** Need a scorecard yet? What variables are what: (Z=x or y) Zh = the Z coordinate of the topmost/leftmost subsector to check tZh = the Z coorindate of the subsector currently being checked Note that Zh and tZh may be negative or greater than 64, so checks against Sectors[txh][tyh] are not ok. ttZh = tZh normalized to 0 <= ttZh < 64 This allows checks against Sectors[ttxh][ttyh] . dZ = the difference in the Z coordinates of obj and this_obj, as adjusted for torriodal space (we can tell if we need to adjust, and if so, how, by comparing tZh and ttZh. If tZh==ttZh, no adjustment is needed. If tZhttZh, add MAX_Z to obj's Z coordinate before checking. Note: we may want to have one standard bboxside for all objects...this would get rid of four indirect references per collision. If we do this, then the pixel maps would still come in fixed sizes (the largest confined to a circle no more than SUBSIZE in diameter, as is the current plan anyway), but this problem would be avoided. */ /* <> ** There were some bugs in the old detection code: for instance, if ** obj->x == this_obj->x, dx will be 0 (as it should), but the collision ** would be ignored because dx < obj->bboxside (assuming obj->bboxside > 0). ** (The previous check started with ** ((dx < this_obj->bboxside) && (dx > obj->bboxside) && ** (dy < this_boj->bboxside) && (dy > obj->bboxside) && ... ** which also lead to the bug where dx = 4, dy = 0, obj->bboxside = 10, ** and this_obj->bboxside = 2; this is obviously a collision, since obj's ** bounding circle overlaps this_obj's bounding circle, but it would not be ** detected.) ** ** (Badcoe's comment noting another problem snipped, since that problem has ** also been fixed. - ) ** ** The previous is fine as long as all the circles are the ** same size, but if they differ then the centers of the circles are ** offset from their bbox-coords (which are measured to a corner, yes ?) ** by different ammounts. ** ___ ** / \ ** | + | ___ ** \___/ / \ The centers of these are at the same separation as their ** | + | bbox corners. ** \___/ ** ** ___ ** / \ ** | + | _____ ** \___/ / \ The centers of these are at a different separation to their ** | | bbox corners. ** | + | ** | | ** \_____/ ** ** The easiest/fastest solution might be for only a small number of different ** circle sizes (say 8) and an array of relative offsets. */ /* <> **possible collision damage implementation: obj->shield -= ((this_obj->velx * this_obj->velx) + (this_obj->vely * this_obj->vely)) * this_obj->mass; this_obj->shield -= ((obj->velx * obj->velx) + (obj->vely * obj->vely)) * obj->mass; Alternate possibility: Calculate total kinetic energy as above, then recalculate after adjusting momentum, and subtract the difference from each of the colliders' shields (half each? proportional to mass?) */ /*-------------------------------------------------------------------------*/ void UN_ReSeed() { /* TO BE WRITTEN */ /* will have to adjust to make sure that not too many objects are in play at ** once...may even remove isolated inanimate objects (or might not?) */ } /*-------------------------------------------------------------------------*/ char UN_NewSector() { /* Called when a sector has been cleared; this allows the player to choose ** a new sector, then calls UN_InitSector() to create that sector. If the ** player has just cleared the last sector, this returns 1 to end the ** game. */ if (curmovie==7) { /* final sector cleared */ AS_ShowMovie(PLAYER_WON); curmovie=8; return 1; } /* TO BE WRITTEN: code that allows the user to choose which sector to go to */ /* Current implementation: player automatically advances one "wave" each ** sector. */ curmovie++; AS_ShowMovie(curmovie); StartAsteroids=curmovie*50; StartFood=0; StartProbes=curmovie*10; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); return 0; /* game continues */ } /*-------------------------------------------------------------------------*/ void UN_InitGame() { /* calls UN_InitSector() and sets anything else that needs to be set at the ** beginning of the game (for instance, making sure that there is only one ** player life object in the Player_Dummy list) */ UN_Object *temp; while (Live_Dummy.next_ob != &Live_Dummy) UN_DeleteObject(Live_Dummy.next_ob); while (Player_Dummy.next_ob != &Player_Dummy) { temp=Player_Dummy.next_ob; UN_ObRemove(temp); UN_ObInsert(temp, &Spare_Dummy); } UN_ObInsert(UN_CreateObject(),&Player_Dummy); curmovie=1; AS_ShowMovie(curmovie); StartAsteroids=curmovie*50; StartFood=0; StartProbes=curmovie*10; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); } /*-------------------------------------------------------------------------*/ char UN_PlayGame() { /* Will be called when a sector has been started, either ** after UN_InitGame() or by a game having been paused in mid ** sector, then unpaused. */ unsigned long ticksleft, nextupdate = FE_Set(); /* how many ticks left until next update, and the time of the next update, ** encoded in a way meaningful to FE and AI */ while (1) { probes_exist = 0; if (User->shield <= 0) { AS_PlayFX(FX_DIE); if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } /* UN_NewLife() returns 1 if no lives left for the player */ for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy;) { tobj = curobj->next; if (curobj->shield <= 0) UN_DeleteObject(curobj); /* is this the only bit that removes the dead ? Or is it just a tidy-up ? ** I ask because surely this *should* be done at the point where the shields ** *became* <=0 ? */ /* No. When the shields become <=0, there is one frame where the FE displays ** the object dying. On the *next* frame, the object is removed. */ curobj = tobj; } for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy; curobj = curobj->next_ob) if (curobj->shield > 0) UN_CheckObject(curobj); if ((ticksleft = FE_GetTicks(nextupdate)) > 0) AI_DoQueue(ticksleft); nextupdate = FE_Update(Sectors, (User->x) % SUBSIZE, (User->y) % SUBSIZE); /* syskeys that aren't handled below handled here */ if ((SYSKEYS) & 4) FE_ToggleSound(); if ((SYSKEYS) & 2) return 2; if ((SYSKEYS) & 1) return MA_ConfirmQuit(2); if (!(probes_exist)) if (UN_NewSector()) return 1; /* We will probably want to change these conditions. */ /* This would be an ideal place to put a possible call ** to UN_ReSeed() if there are too few or too many objects. */ } } /* Return codes for UN_PlayGame: 0 = quitting, 1 = game over, 2 = paused */ From dl.ac.uk!mbbad Wed Oct 25 05:00:20 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t84V9-000fJRC; Wed, 25 Oct 95 05:00 PDT Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id MAA27032 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Wed, 25 Oct 1995 12:54:14 +0100 Precedence: first-class Received: by s-crim1.dl.ac.uk (931110.SGI/930817.MJE) for ag-directors@alnilam.krl.caltech.edu id AA28755; Wed, 25 Oct 95 12:54:08 +0100 Date: Wed, 25 Oct 1995 12:54:06 +0100 (BST) From: "I. Badcoe" Subject: Re: FE status? Cc: AG Directors In-Reply-To: <199510231918.UAA12834@laurel.stud.phil.ruu.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 23 Oct 1995, Martijn Faassen wrote: > Hi there, > I'm currently trying to make the various bits of universe compilable. > To see what the compiled program actually does, front end code is necessary. :) > So, what's the status of the front end code? I know there's poc3, but > anything after that? Do you need a list of functions that universe > needs? (you also need a definition of how universe expects keypress > info, I think, looking into that now). > Currently I'm trying to compile the code on a linux machine, with gcc. > Naturally the dos FE won't work with that. But, I also have gcc for dos > (DJGPP), which can compile flat mode 32 bits, etc. It's hard for me to > make the front end code running on that at all, as I'm no expert on > assembly code, etc. Perhaps, if we want to support DJGPP that is, somebody > in front end can look at that? It'll be greatly appreciated. That way I > can get the code to compile and run at my home machine. :) > I think DJGPP Is a good choice, mainly because it's free (and fast), so > anybody can get it. > So, please? Please? :) Hi, I've pissed about with graphics in djgpp so I *could* do it but it will have to wait a while. If we could find another djgpp user this would be kool on account of gcc being available on many machines. Badders p.s If I did do this, you'd owe me a beer. From compuserve.com!71044.2164 Wed Oct 25 09:40:46 1995 Return-Path: <71044.2164@compuserve.com> Received: from dub-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t88sb-000fJVC; Wed, 25 Oct 95 09:40 PDT Received: by dub-img-5.compuserve.com (8.6.10/5.950515) id MAA22881; Wed, 25 Oct 1995 12:34:58 -0400 Date: 25 Oct 95 12:30:12 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Directors Subject: universe.c (incomplete revision) Message-ID: <951025163012_71044.2164_GHI94-3@CompuServe.COM> ---------- Forwarded Message ---------- From: Martijn Faassen, INTERNET:Martijn.Faassen@phil.ruu.nl TO: ag universe, INTERNET:AG-UNIVERSE@ALNILAM.KRL.CALTECH.EDU DATE: 10-24-95 1:05 PM RE: universe.c (incomplete revision) Sender: faassen@phil.ruu.nl Received: from alnilam.krl.caltech.edu by dub-img-2.compuserve.com (8.6.10/5.950515) id PAA28730; Tue, 24 Oct 1995 15:34:55 -0400 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t7pB0-000fJxC; Tue, 24 Oct 95 12:38 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.7.1/8.6.12) with ESMTP id UAA21930 for ; Tue, 24 Oct 1995 20:32:40 +0100 (MET) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.7.1/8.6.12) id UAA19789 for ag-universe@alnilam.krl.caltech.edu; Tue, 24 Oct 1995 20:32:38 +0100 (MET) From: Martijn Faassen Message-Id: <199510241932.UAA19789@laurel.stud.phil.ruu.nl> Subject: universe.c (incomplete revision) To: ag-universe@alnilam.krl.caltech.edu (ag universe) Date: Tue, 24 Oct 1995 20:32:37 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit /* Universe code version 0.52, copyright (c) 1995 us * Last modified by Martijn, October 1995 * Made it compilable except for various undefined * functions and variables. */ /* I haven't checked all of the code closely yet, so this could * definitely be revised further, especially some cleaning up * of redudant comments, etc */ #include /* for sin and cos */ #include /* for definition of NULL */ #include "alife.h" #include "universe.h" /* ** Renamed (more meaningful and also Capitalized for important arrays): ** objects -> Live_Objects ** spares -> Spare_Objects ** sector -> Sectors ** thrustcost ->ThrustCost ** ** *_Objects are all gone now (Sic Transit Gloria Mundi) instead we ** now do all list access *through* the dummy object, e.g. ** Live_Dummy.next_ob is the first live object. ** We could have MACRO's defined for these but do we really need ** them ? */ /* ** Inserts an UN_Object into the specified object list (which ** means Live_Objects, Spare_Objects or Player_Objects at the moment). ** ** Now that this is doubly linked and we have dummies, we no longer need ** pointers to the lists and can access them through the dummies ** themselves . ** ** Assumes that the UN_Object was correctly removed from any ** previous list it belonged to. */ /* Description: * Inserts UN_Object ob as next object of UN_Object dummy, * in a doubly linked list. * Comments: * Assumes that the UN_Object was correctly removed from any * previous list it belonged to. (like the Spare_Objects list) */ void UN_ObInsert(UN_Object *ob, UN_Object *dummy) { ob->prev_ob = dummy; ob->next_ob = dummy->next_ob; dummy->next_ob->prev_ob = ob; dummy->next_ob = ob; } /* ** Removes an UN_Object from whatever object list it belongs to. ** ** Will probably crash if the UN_Object wasn't in one.*/ /* Description: * Removes UN_Object from doubly linked list it belongs to. * Comments: * WARNING: UN_Object has to be in a doubly linked list! */ void UN_ObRemove(UN_Object *ob) { (ob->next_ob)->prev_ob = ob->prev_ob; (ob->prev_ob)->next_ob = ob->next_ob; } /* ** Next two routines are exactly like previous two but act on sector ** lists. */ /* Description: * Inserts an object into a subsector list. * Comments: * Assumes that this object was correctly removed from its previous * subsector list */ void UN_HashInsert(UN_Object *ob, UN_Object **list) { ob->prev_hash = list; ob->next_hash = *list; (*list)->prev_hash = &(ob->next_hash); *list = ob; } /* Description: * Removes object from its subsector list. * Comments: * Object has to be in subsector list! */ void UN_HashRemove(UN_Object *ob) { (ob->next_hash)->prev_hash = ob->prev_hash; *(ob->prev_hash) = ob->next_hash; } /* Description: * Move an UN_Object from one sector list to another. */ void UN_Shift(long sectx, long secty, UN_Object * obj) { /* first remove us from our old list */ UN_HashRemove(obj); /* now insert us at the start of the new list */ UN_HashInsert(obj, &(Sectors[sectx][secty])); } /* initialize starting UN_Objects (as in, we *know* that we'll need at least ** STARTOBJECTS UN_Objects, so let's allocate them while the user expects ** initialization lag) */ /* ** I'm assuming that this gets called exactly once. ** ** That's the current plan. */ /* Description: * Initializes starting UN_Objects. * Comments: * We know we'll need at least STARTOBJECTS Un_Objects anyway, so * let's allocate them while the user expects initialization lag. * Assumed is that this function gets called exactly once. */ void UN_InitTable() { int i,j; Live_Dummy.prev_ob = &Live_Dummy; /* make a closed doubly-linked list */ Live_Dummy.next_ob = &Live_Dummy; /* with one member */ Spare_Dummy.prev_ob = &Spare_Dummy; /* ditto */ Spare_Dummy.next_ob = &Spare_Dummy; Player_Dummy.prev_ob = &Player_Dummy; /* ditto */ Player_Dummy.next_ob = &Player_Dummy; /* ** The following leaves undefined UN_Objects in the Spare_Objects list, ** UN_InitSector will initialise and move them to Live_Objects ** as things are created. */ tobj = (UN_Object *)malloc(sizeof(UN_Object) * STARTOBJECTS); for (i = 1; i < STARTOBJECTS; i++) { /* Removed & in front of Spare_Objects, is already a pointer */ UN_ObInsert(tobj++, Spare_Objects); } /* now to initialize UN_sin[] and UN_cos[] lookup tables */ for (i = 0; i < 255; i++) { UN_sin[i] = (float) sin((double)i * (double)TWOPI / (double)256.); UN_cos[i] = (float) cos((double)i * (double)TWOPI / (double)256.); /* GNU C (which is probably one of the compilers we will be working with) * expects radians, so I changed it to that. (Since radians are ANSI also) * Also I sprinkled plenty of typecasts all over the thing, to make sure * it doesn't do that wrong. */ } } /* used to insert a new UN_Object into the ** objects list and its Sectors[][] list; assumes that nothing critical is ** being pointed to only by obj->prev_hash, obj->next_hash, obj->next_ob, or ** obj->prev_ob ** ** Note: I've updated this function but the things it does don't ** make a lot of sense 'cos the UN_Objects list and sectors lists ** aren't likely to be adjusted at the same time now ** we have Spare_Objects. */ /* Description: * Inserts a UN_Object into the objects list and its Sectors[][] list * at the same time. * Comments: * As we are working with Spare_Objects now, this function is probably * obsolete. * Assumes nothing critical is being pointed to by obj->prev_hash, * obj->next_hash, obj->next_ob, and obj->prev_ob. */ void UN_InsertObject(long sectx, long secty, UN_Object *obj) { /* Removed & in front of Live_Objects */ UN_ObInsert(obj, Live_Objects); UN_HashInsert(obj, &(Sectors[sectx][secty])); } /* Description: * - Returns a (new) UN_Object (from the Spare_Objects list, or newly * allocated if none available. * * Comments: * - Don't assume anything about initial conditions of any value in the * UN_Object (including next_ob and prev_ob)! So EVERY value has to be * initialized. * - Doesn't yet include check if there is sufficient memory left! */ UN_Object *UN_CreateObject() { UN_Object *tob; /* formerly this declaration was inside the function, * which isn't possible in ANSI C */ /* There was a bug here, != should be ==, so I corrected this * (if I understand this correctly!) */ if (Spare_Dummy.next_ob == &Spare_Dummy) { /* if there is no spare object left, allocate new object */ return (UN_Object *)malloc(sizeof(UN_Object)); /* WARNING: Include free memory check! */ } else { /* there are still spare objects, so return one */ tob = Spare_Dummy.next_ob; UN_ObRemove(tob); return tob; } } /* Description: * Removes an object in the Live_Objects list from that list, and also * removes it from its Sectors[][] list. * It will then be inserted into the Spare_Objects list, so later the * memory can be reused by a new object. */ void UN_DeleteObject(UN_Object * obj) { UN_ObRemove(obj); UN_HashRemove(obj); UN_ObInsert(obj, &Spare_Dummy); } /* Description: * UN_CheckObject is called for each object each 'tick' */ void UN_CheckObject(UN_Object * obj) { curwhat = obj->what; /* type of UN_Object is stored in curwhat */ curpic = 0; /* get keys & virtual keys */ switch (curwhat) { case PLAYER: /* this is the player */ obj->extra.animate.actions = FE_GetKeys(); /* get the real keypresses */ break; /* <<1>> */ case PROBE: /* this is a probe */ probes_exist++; /* count surviving probes */ /* get the virtual keypresses from a short AI routine - * real alife work is done elsewhere */ obj->extra.animate.actions = AI_GetKeys(obj); break; /* case missile (probe remote control, and standard control routines) */ /* case SUPPLY */ } /* end of switch(curwhat) */ if (curwhat <= MISSILE) { /* this is an animate UN_Object */ UN_Animate(obj); } /* end if animate */ /* Note that curpic is set in the code that was move to UN_Animate(); ** it might be clearer to move all curpic setting code in that function ** (which for now consists of detecting thrusting and braking) back into ** this function. */ if (User->extra.animate.target == obj) { curpic |= TARGETPIC; } AS_SetPic(obj->pic, curpic | obj->facdir); /* <<2>> */ UN_Movement(obj); /* Movement update */ } /* ** <<1>> this makes all objects of type PLAYER act in exactly the same ** way...we might want to have some other means of controlling PLAYER ** objects that aren't currently being controlled by the player. */ /* * My assumption was that if we have objects 'owned' by the player but * currently not controlled by the player, then they will have an extra * variable set somewhere 'owned by the player'. (or will be in a special * 'owned by player list') Therefore, their 'what' variable will not * be PLAYER. It is assumed only one such object is around at the * time. (until we create a multiplayer networked version :) */ /* ** <<2>> Sets the current picture so FE can just display it if it is visible, ** also allows cycling of colors. We may want to move this to after the ** collision detection. ** ** Do you mean "&" in the previous ? Isn't "|" more likely ? ** ** No, I meant to use "|", since "&" would set the parameter to 0. ** ** Also, "(facdir + 256) % 256" could be avoided if facdir was an unsigned ** char which must remain in 0 - 255 with automatic {und,ov}erflow ?? ** ** Elsewhere in the code facdir was assumed to be +ve so I scrapped the ** previous bit. */ /* Description: * Updates animate objects (turning, thrusting). */ void UN_Animate(UN_Object *obj) { tempx = obj->x / SUBSIZE; /* store original subsector */ tempy = obj->y / SUBSIZE; /* Wouldn't a bitshift be faster for this? We may * also want to move this to UN_Movement, if it doesn't break * anything. */ if (obj->extra.animate.actions & THRUST) { /* forward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx += (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely += (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ curpic = THRUSTPIC; } else { /* not enough energy for thrust */ /* FE call here for thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, THRUST_FAIL); /* <> */ } } /* end of not enough energy code */ } /* end of THRUST code */ else if (obj->extra.animate.actions & BRAKE) { /* backward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx -= (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely -= (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this brake thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ curpic = BRAKEPIC; } else { /* not enough energy for brake thrust */ /* FE call here for brake thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, BRAKE_FAIL); /* "hardware" interrupt */ } } /* end of not enough energy code */ } /* end of BRAKE code - end of THRUST/BRAKE code */ /* * NOTE: we might want to kick out different turn speeds, and use a * standard turnspeed instead for each object */ if (obj->extra.animate.actions & LEFT) { /* turn to the left */ /* <> */ obj->facdir = (obj->facdir - obj->extra.animate.turn) & 0xff; /* <> */ } /* end of LEFT code */ else if (obj->extra.animate.actions & RIGHT) { /* turn to the right */ /* turning to the right, so clockwise, means increasing angle */ obj->facdir = (obj->facdir + obj->extra.animate.turn) & 0xff; } /* end of RIGHT code */ /* <> */ /* ** New target code, it's simpler. ** However, this has an important feature that the objects will ** always come up in the same order (which wasn't true for ** Adrian's hash-by-hash version). ** ** Still needs work, though. Won't hang if the previous target ** has moved out of range and there are no other targets, but only because ** you can target yourself :->. */ if (curwhat == PLAYER) { if (obj->extra.animate.actions & NEXTTARGET) { /* cycle to next target */ do { do { obj->extra.animate.target = obj->extra.animate.target->next_ob; } while (ABS(obj->extra.animate.target->x - obj->x) > 5 || ABS(obj->extra.animate.target->y - obj->y) < 5); } while (obj->extra.animate.target != &Live_Dummy); } else if (obj->extra.animate.actions & LASTTARGET) { /* cycle to previous target */ do { do { obj->extra.animate.target = obj->extra.animate.target->next_ob; } while (ABS(obj->extra.animate.target->x - obj->x) > 5 || ABS(obj->extra.animate.target->y - obj->y) < 5); } while (obj->extra.animate.target != &Live_Dummy); } } /* Minor problems with the targetting code: ** #1: Comparing x and y will compare the universe coordinates, in which 5 ** is a very small distance. Better to compare x >> SUBPOWER and ** y >> SUBPOWER. ** #2: This cycles targetting the same way whether obj specified to target ** the previous target or the next target; those two actions are ** supposed to cycle the current target in different directions. ** #3: Can only select targets in the same row as the player (large x ** and small y differences are the only ones accepted...both comparisons ** should use < or <=; neither should use > or >= if an object can ** target itself). */ /* I don't see the reasons for this '> 5' stuff at all. Can somebody * please explain this? (In general I don't like seeing numbers like '5' * appear in code at all, I'd prefer a #define here) * And, since bullets are part of the main object lists, this means * bullets can currently be targetted also. Should this be allowed? * (staying clear of the targetting code for now) */ /* need to add in FIRE for PLAYER/PROBE */ /* need to add in cycle weapon code for PLAYER/PROBE */ /* one possibility: have objects outside of the objects list be the * prototypes for each weapon, with next_hash/prev_hash forming a circular * double-linked list for each object; cycle weapon would then get the next (or * previous) object on that list, while fire would merely make a duplicate of * that weapon into the objects list, editing velocity, position, and (if * needed) target as needed */ /* need to add in eat code for PLAYER/PROBE */ /* need to add in energy to shield code for PLAYER/PROBE/SUPPLY */ /* need to add in breed stuff */ /* need to add in pick up/drop */ /* these last two could merely set flags (for instance, * object->extra.animate.actions & BREED) that could be * checked if the object bumps into another object, since * fertilization and grabbing will only be processed when an * object that is trying to do that comes into contact with * another one */ /* Another possibility for breed/grab/eat is to use the targetting code, * and enable breeding/grabbing/eat at a limited distance, so the probes won't * have to do complicated maneuvering just to grab something..*/ } /* ** <> assuming navigation system with north = 0, clockwise increase ** calculate vector changes */ /* ** <> hardware interrupt for AI, note that hardware interrupt calls ** don't do anything directly; the interrupt is just registered, ** later the interrupt handler will handle it */ /* <> turning to left, so counterclockwise, means decreasing angle ** ** % operator doesn't work here, because when turning left the facdir ** will never rise above 255. Instead code is needed to handle facdir ** < 0. This code will break with turnspeed > 256 :) ** ** I've changed it to use "&" which should work on all 2's compliment ** systems (which I *think* is ANSI for C). ** ** Although it is widely used, 2's compliment is apparently not ANSI C. ** There is a good chance that all of the systems we write this for will ** be 2's compliment, however, so maybe we should check with FE before ** changing this just in case we don't have to. */ /* In general, I suggest we make a list of all the non-ANSI assumptions * we've made. (like size of long, under/overflow, and 2's compliment) * */ /* ** <> code and comments removed ** if (obj->facdir < 0) { ** obj->facdir += 256; ** } ** ** alternatively (if faster?) use: obj->facdir = (256 + (obj->facdir - ** obj->extra.animate.turn)) % 256 */ /* ** <> excised entire target code and rewrote . ** ** ** target code for player only...probes handle this differently, and ** this only allows the player to target things in the 11*11 ** subsectors nearest to the subsector that the player is in, since ** this is what will be on the player's screen...and while we could ** allow the player to target anything, the player will probably not ** want to spend the time to cycle through everything that's out of ** sight to target an incoming food source ** ** ** note: this has bugs in it (especially the "last target" part), * so ** IGNORE the target code for now. ** ** if (obj->extra.animate.actions & NEXTTARGET) { ** cycle to next target ** ** if ((obj->extra.animate.target)->next_hash != NULL) ** obj->extra.animate.target = ** (obj->extra.animate.target)->next_hash; ** else { ** search through sectors to find a target ** ** long x = ((obj->extra.animate.target)->x / SUBSIZE), y = ** ((obj->extra.animate.target)->y / SUBSIZE); ** x++; ** if (x > tempx + 5) { ** x = tempx - 5; ** y++; ** } ** if (y > tempy + 5) ** y = tempy - 5; ** while (Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS] == ** NULL) { ** x++; ** if (x > tempx + 5) { ** x = x - 11; ** y++; ** if (y > tempy + 5) ** y = y - 11; ** } ** } ** obj->extra.animate.target = ** Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS]; ** } ** } ** sorry for the tab shifts above, but I don't know if I can break up the ** Sectors[formula][formula] without inducing a parsing error ** ** end of "next target" code ** ** else if (obj->extra.animate.actions & LASTTARGET) { ** find previous target ** ** object *tar = obj->extra.animate.target; ** if (tar->prev_hash != ** &(Sectors[tar->x >> SUBPOWER][tar->y >> SUBPOWER])) ** obj->extra.animate.target = *(tar->prev_hash); ** else { ** cycle through sectors to find previous ** * target ** ** long x = (tar->x >> SUBPOWER), y = (tar->y >> SUBPOWER); ** x--; ** if (x < tempx - 5) { ** x = tempx + 5; ** y--; ** } ** if (y < tempy - 5) ** y = tempy + 5; ** while (Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS] == ** NULL) { ** x--; ** if (x < tempx - 5) { ** x = x + 11; ** y--; ** if (y < tempy - 5) ** y = y + 11; ** } ** } ** obj->extra.animate.target = ** Sectors[(x + NUMSUBS) % NUMSUBS][(y + NUMSUBS) % NUMSUBS]; ** } ** } ** end of "last target" code; also end of player's "change target" code ** ** */ /* Description: * Called when the player's probe has just died. This routine determines * if the player has any 'lives' left. If so, it turns one of the player's * 'life' objects into the player object, sets whatever variables that are * needed for it to be the player, then returns 0. If the player is * out of lives, it returns 1, which the main play lookps takes as a signal * to end the game. * Comments: * No parametres should be needed, since the object and subsector lists * are global. */ short UN_NewLife() { /* this depends on how we implement 'lives'. An idea I've been toying with * is to let all lives be either eggs, or even active probes. When the player * dies the player owned eggs/probes are checked, and one is picked to * reincarnate the player. * Also, a nice animation would be required (egg hatching, whatever) * in this case. */ if (Player_Dummy.prev_ob == &(Player_Dummy)) return 1; else { UN_CreatePlayer(User->x,User->y); /* default initial placement */ return 0; } } /** needs: UN_ReSeed(), ** No, I don't think so re-seeding is different, when re-seeding ** (if I understand it and if we really want it) there's a whole load of ** stuff that may be already set up. Whereas here, we have to do it all. ** ** I put that in because I thought that UN_InitSector() would call ** UN_ReSeed() to actually do the object creation. * * I am still dubious about the reseeding. Reseeding to maintain * more or less uniform object density will work against interesting * pattern formation. Besides, would reseeding only work on asteroids? * If we decide to implement cellular automaton like plants or something * like this, reseeding may become an unnecessary concept. cellular automata * may gobble up our CPU though.. */ /* ** This was the brief: ** ** Initializes a sector (including "dummy" objects at the end of subsector ** lists), populates it with food sources, asteroids, and probes of the ** appropriate level, then places the player (object #0, genotype #0) ** somewhere in the sector. Also does anything else that is needed at the ** start of a sector. I do not know what parameters will be needed; ** you will have to determine what info is needed. ** ** Comments: * * Does the player have to be 'object #0' 'genotype #0'? Do we indeed still * have numbered objects at all? */ /* Description: * Initializes a sector (including "dummy" objects at the end of subsector * lists), populates it with food sources, asteroids, and probes, then * places the player somewhere in the sector. */ void UN_InitSector() { int i, j; /* Tidy Object lists by just dumping any Live_Objects onto * Spare_Objects. (This leaves inactive Player_Objects untouched.) */ while((tobj = Live_Dummy.next_ob) != &Live_Dummy) { UN_ObRemove(tobj); UN_ObInsert(tobj, &Spare_Dummy); } /* This could be done as a single transfer but I'm too tired */ /* Just blank the hash tables. */ for(i = 0; i < NUMSUBS; i++) { for(j = 0; j < NUMSUBS; j++) { Sectors[i][j] = &(Dummies[i][j]); Dummies[i][j].prev_hash = &(Sectors[i][j]); Dummies[i][j].next_hash = &(Dummies[i][j]); /* next_hash shouldn't ever be referenced but this may be safer */ } } UN_CreatePlayer(0,0); /* As good a place as any to start :) */ for(i = 0; i < StartAsteroids; i++) { UN_CreateAsteroid(); } for(i = 0; i < StartFood; i++) { UN_CreateFood(); } for(i = 0; i < StartProbes; i++) { UN_CreateProbe(); /* This isn't the only place a genome could come from. This is where 'seed' ** genomes arise (from the archive of previous heroes ? (In which case the ** archiving routines might eventually fall into a different function heading ** AR_* ?)). */ /* True, however, UN_CreateProbe() will always need to have a genome for ** the created probe, so I've moved the genome creation call to inside the ** UN_CreateProbe() routine. */ /* But genome creation depends on universe circumstances. That is, if * two probes cooperate to lay an egg, the genome creaton code needs to * do something entirely different than when a random probe is thrown * into the universe, or a nonrandom probe is retrieved from the archives. * */ } /* ** ... ** Insert any other object type you want to start with here. */ } /* Description: * Pulls a player object off the waiting stack (Player_Dummy) and sets it up * as the active player. If there aren't any on the stack, behaviour * is undefined (might ultimately create a default one but I don't yet * know enough to say what 'default' is). * Comments: * Default: this procedure should not be called if * Player_Dummy.prev_ob == &(Player_Dummy). * This implies something like UN_CreatePlayerLife. */ void UN_CreatePlayer(UN_coord x, UN_coord y) { User = Player_Dummy.prev_ob; /* Use last craft from list (e.g. FIFO) * as new ones will be added to front. */ User->x = x; User->y = y; User->velx = 0; User->vely = 0; User->facdir = 0; User->extra.animate.target = User; User->extra.animate.gtype = (genotype*)NULL; User->extra.animate.actions = 0; /* presumably all other properties are set-up by whatever process * generates the members of Player_Objects . * * Possible exceptions, shield and energy (always start 'full' ?). */ UN_ObRemove(User); UN_ObInsert(User, &Live_Dummy); UN_HashInsert(User, &Sectors[x >> SUBPOWER][y >> SUBPOWER]); AL_InitPlayerGenome(User); /* my previous comments on this apply. Does a player need a genome * at all? And should it be initialized here, instead of wherever * the object that is to be player is initialized? (what if this is * a probe the player can take over, for instance) */ } /* Description: * Creates an asteroid. */ void UN_CreateAsteroid() { UN_Object *temp; temp = UN_CreateObject(); temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * AsteroidVelocity) - AsteroidVelocity; temp->vely = UN_Random(2 * AsteroidVelocity) - AsteroidVelocity; temp->facdir = UN_Random(256); temp->extra.animate.target = temp; temp->extra.animate.gtype = (genotype*)NULL; temp->extra.animate.actions = 0; /* may include shield and energy setting here */ UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, &Sectors[temp->x >> SUBPOWER][temp->y >> SUBPOWER]); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER, temp); } /* Do asteroids have genomes at all? * My idea was that only probes, and possibly some missiles * and also possibly the player object, can have genomes. * Missiles in case they have evolved behaviour, and the player * object in case it is a 'taken over' probe (egg). A nice * special effect would be if heavy damage (or a special weapon, or * or whatever) temporarily makes the player lose control over his/her * ship, so that the probe controlling genome can take over! * (so the player can watch in agony while the ship does all kinds * of terribly unwanted behavior) * * Also, I'm assuming that any special weapon properties *except* evolving * behavior are all universe defined, and belong in universe objects. * (perhaps a special weapons object category). The only thing * alife has to do is create an 'investment' strategy for each probe, * which can evolve. (that is, some probes will invest more in * heavy missile #1, and others more in bullet #3, and others again * like huge shields, and some others like more thrust) */ AL_InitAsteroidGenome(temp); } /* ** Creates food (I can't remember what food is like so I'll skip this) . ** ** How long has it been since you've eaten? :) */ void UN_CreateFood() { /* To be determined */ } /* Description: * Creates a probe (without genome). */ void UN_CreateProbe() { UN_Object *temp; temp = UN_CreateObject(); temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * ProbeVelocity) - ProbeVelocity; temp->vely = UN_Random(2 * ProbeVelocity) - ProbeVelocity; temp->facdir = UN_Random(256); temp->extra.animate.target = User; /* (:-> */ temp->extra.animate.gtype = (genotype*)NULL; temp->extra.animate.actions = 0; /* ** presumeably all other properties are set-up by the addition ** of the genome . */ /* the probe genome would contain information on what kind of weapons, * shield size, etc, to invest in most. */ UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, &Sectors[temp->x >> SUBPOWER][temp->y >> SUBPOWER]); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER, temp); } AL_InitProbeGenome(temp); /* I'll have to think of the different ways a probe genome can be * initialized/created (random, recombination, from archives) */ } /* Description: * Returns 1 if the newly created object passed as a parameter overlaps * any other object currently in play; returns 0 otherwise. */ int UN_Collision(UN_Object *which) { /* Need the appropriate parts of movement moving in here. ** Might need two versions of this, one for set up and one for ** play but I think one will crack it. */ /* TO BE WRITTEN */ /* For now, just returns 0, so new objects might appear in the middle of ** old ones. */ return 0; } /* Description: * Moves obj, and determines if it collided into anything */ void UN_Movement(UN_Object *obj) { UN_Object *this_obj; /* might want to make this a global variable instead * for speed */ obj->x += obj->velx; obj->y += obj->vely; /* <> */ subx = obj->x >> SUBPOWER; suby = obj->y >> SUBPOWER; /* did this UN_Object move into a different subsector? */ if ((subx != tempx) || (suby != tempy)) UN_Shift(subx, suby, obj); /* update sector lists */ /* <> */ xh = ((obj->x - SUBSIZE + 1) >> SUBPOWER); yh = ((obj->y - SUBSIZE + 1) >> SUBPOWER); /* This is to get the left and below squares ? , ** (subx - 1) & 0xQQQQ might be quicker. */ /* It might be, but then we'd have to re-compute the sector number if ** obj->x or obj->y < (SUBSIZE-1) when we checked the object's current ** sector. */ for (txh = xh; txh < xh + 2; txh++) { for (tyh = yh; tyh < yh + 2; tyh++) { ttxh = (txh + NUMSUBS) % NUMSUBS; ttyh = (tyh + NUMSUBS) % NUMSUBS; /* Not sure we need the "+ NUMSUBS" 'cos xh & txh are now always +ve */ /* xh and txh can be negative if obj->x < (SUBSIZE-1). */ this_obj = Sectors[ttxh][ttyh]; while (this_obj != NULL) { if ((this_obj == obj) || (this_obj->shield <= 0)) continue; /* Can't collide with yourself, and a bullet's explosion can only hit one ** other object per object that the bullet contained. */ /* Bullets have shields < 0 after one collision ? */ /* Bullets' shields are set to 0 upon collision since they're supposed to ** die after one collision anyway... */ if (ttxh == txh) dx = obj->x - this_obj->x; else if (ttxh < txh) dx = obj->x - this_obj->x - (MAX_X); else dx = (MAX_X) + obj->x - this_obj->x; if (dx<0) dx*=(-1); if (ttyh == tyh) dy = obj->y - this_obj->y; else if (ttyh < tyh) dy = obj->y - this_obj->y - (MAX_Y); else dy = (MAX_Y) + obj->y - this_obj->y; if (dy<0) dy*=(-1); /* previous section can probably be made simpler if we also re-do ** the following if statement, 'cos only one term of the boolean will ** apply to each conditional above. */ if (((dx < this_obj->bboxside) || (dx < obj->bboxside)) && ((dy < this_obj->bboxside) || (dy < obj->bboxside)) && ((dx * dx) + (dy * dy) < (((this_obj->bboxside + obj->bboxside) >> 1) ** 2))) { /* <> !!! */ /* we have a collision between obj and this_obj, so handle it */ if ((this_obj->what == BULLET) || (this_obj->what == MISSILE) || (obj->what == BULLET) || (obj->what == MISSILE)) { if ((obj->what == BULLET) || (obj->what == MISSILE)) { this_obj->shield -= obj->extra.bullet.damage; obj->shield = 0; AS_SetPic(obj->pic, EXPLODE); if (this_obj->shield <= 0) AS_SetPic(this_obj->pic, EXPLODE); } if ((this_obj->what == BULLET) || (this_obj->what == MISSILE)) { obj->shield -= this_obj->extra.bullet.damage; this_obj->shield = 0; AS_SetPic(this_obj->pic, EXPLODE); if (obj->shield <= 0) AS_SetPic(obj->pic, EXPLODE); } } else if ((obj->what <= SUPPLY) && (obj->extra.animate.target == this_obj)) { /* code to handle breeding, grabbing, etc. */ } else if ((this_obj->what <= SUPPLY) && (this_obj->extra.animate.target == obj)) { /* same code with this_obj and obj reversed */ /* not necessary surely 'cos it'll get called in reverse ** when this_obj is itself collision detected. */ /* After the "generic collision" code below is called on this pass, which ** is not necessarily desirable...especially if we implement collision ** damage at M4. Plus, if this_obj is going fast enough, it might fly ** over obj entirely on its next movement check, which means no collision. ** */ } else if ((this_obj->what == STICKY) &&(obj->what == STICKY)) { /* merge two sticky bricks into one object */ } else { /* objects bounce off of each other */ tempx = obj->velx * obj->mass; tempy = obj->vely * obj->mass; /* <> */ obj->velx = (this_obj->velx * this_obj->mass) / obj->mass; obj->vely = (this_obj->vely * this_obj->mass) / obj->mass; this_obj->velx = tempx / this_obj->mass; this_obj->vely = tempy / this_obj->mass; } } this_obj = this_obj->next_hash; } } } } /* <> ** if (obj->velx >= 0) ** obj->x += obj->velx; ** else ** obj->x -= (-1) * (obj->velx); ** ** if (obj->vely >= 0) ** obj->y += obj->vely; ** else ** obj->y -= (-1) * (obj->vely); ** ** I didn't get the previous two if's at all ! ** Isn't "- (-1) * x", identical to "+ x" ? ** remember that unsigned numbers underflow happily as well as overflow. ** (I may be wrong but I'd be suprised) ** ** torrodial space needs no implementation: overflow and underflow should ** take care of this for us */ /* <> ** detect collisions ** ** moved the next comment from inside the loops so I can read it ** ** Need a scorecard yet? What variables are what: (Z=x or y) Zh = the Z coordinate of the topmost/leftmost subsector to check tZh = the Z coorindate of the subsector currently being checked Note that Zh and tZh may be negative or greater than 64, so checks against Sectors[txh][tyh] are not ok. ttZh = tZh normalized to 0 <= ttZh < 64 This allows checks against Sectors[ttxh][ttyh] . dZ = the difference in the Z coordinates of obj and this_obj, as adjusted for torriodal space (we can tell if we need to adjust, and if so, how, by comparing tZh and ttZh. If tZh==ttZh, no adjustment is needed. If tZhttZh, add MAX_Z to obj's Z coordinate before checking. Note: we may want to have one standard bboxside for all objects...this would get rid of four indirect references per collision. If we do this, then the pixel maps would still come in fixed sizes (the largest confined to a circle no more than SUBSIZE in diameter, as is the current plan anyway), but this problem would be avoided. */ /* <> ** There were some bugs in the old detection code: for instance, if ** obj->x == this_obj->x, dx will be 0 (as it should), but the collision ** would be ignored because dx < obj->bboxside (assuming obj->bboxside > 0). ** (The previous check started with ** ((dx < this_obj->bboxside) && (dx > obj->bboxside) && ** (dy < this_boj->bboxside) && (dy > obj->bboxside) && ... ** which also lead to the bug where dx = 4, dy = 0, obj->bboxside = 10, ** and this_obj->bboxside = 2; this is obviously a collision, since obj's ** bounding circle overlaps this_obj's bounding circle, but it would not be ** detected.) ** ** (Badcoe's comment noting another problem snipped, since that problem has ** also been fixed. - ) ** ** The previous is fine as long as all the circles are the ** same size, but if they differ then the centers of the circles are ** offset from their bbox-coords (which are measured to a corner, yes ?) ** by different ammounts. ** ___ ** / \ ** | + | ___ ** \___/ / \ The centers of these are at the same separation as their ** | + | bbox corners. ** \___/ ** ** ___ ** / \ ** | + | _____ ** \___/ / \ The centers of these are at a different separation to their ** | | bbox corners. ** | + | ** | | ** \_____/ ** ** The easiest/fastest solution might be for only a small number of different ** circle sizes (say 8) and an array of relative offsets. */ /* <> **possible collision damage implementation: obj->shield -= ((this_obj->velx * this_obj->velx) + (this_obj->vely * this_obj->vely)) * this_obj->mass; this_obj->shield -= ((obj->velx * obj->velx) + (obj->vely * obj->vely)) * obj->mass; Alternate possibility: Calculate total kinetic energy as above, then recalculate after adjusting momentum, and subtract the difference from each of the colliders' shields (half each? proportional to mass?) */ /*-------------------------------------------------------------------------*/ void UN_ReSeed() { /* TO BE WRITTEN */ /* will have to adjust to make sure that not too many objects are in play at ** once...may even remove isolated inanimate objects (or might not?) * * - Adjust to make sure not too many objects in play at once..sure * - Adjust to make sure not too many objects are in one place at once.. * I disagree, this may hinder interesting pattern formation effects. * - Remove isolated inanimate objects: Don't think this is easy to * implement, and may not be desirable. Perhaps there's some probe * species possible which counts on these isolated objects. Also, * if we implement things like plant seeds, they shouldn't be removed. */ } /*-------------------------------------------------------------------------*/ /* : Ideology note :) * I'm still more in favour of the 'contineous model' of the universe. * That is, no new 'levels', but one single play field. * Reason: * - The longer a play field is active, the more interesting things may * evolve in it. Also interesting (plant) pattern formation takes time. * - In this kind of system, it may be too hard to determine things like * 'progressive difficulty' anyway. How to determine which level is * tougher, while the level keeps adapting to the player anyway? Very hard * to say. * We can prevent the 'dying out' of this field by reintroducing * (I suppose this would be reseeding :) 'old heros' into the field. * To have some pauses and changes in play, we can have occasional additions * of new technology/information, accompanied by movies. * * Perhaps a good compromise is a 'scenario' type approach. The player can * choose at the beginning whatever scenario he or she wants to play, and * the scenarios have varying difficulty/properties, dependent on what * we seed them with initially, and all kinds of options set and not set. * * Next to these 'standard scenarios' we can also have the player design * scenarios him/herself, by setting all kinds of options (and there will * be many options possible). * * * My proposal is to ignore level increases and so on for now, and to focus * on getting a single field working (we are doing this anyway..) * * */ char UN_NewSector() { /* Called when a sector has been cleared; this allows the player to choose ** a new sector, then calls UN_InitSector() to create that sector. If the ** player has just cleared the last sector, this returns 1 to end the ** game. */ if (curmovie==7) { /* final sector cleared */ AS_ShowMovie(PLAYER_WON); curmovie=8; return 1; } /* TO BE WRITTEN: code that allows the user to choose which sector to go to */ /* Current implementation: player automatically advances one "wave" each ** sector. */ curmovie++; AS_ShowMovie(curmovie); StartAsteroids=curmovie*50; StartFood=0; StartProbes=curmovie*10; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); return 0; /* game continues */ } /*-------------------------------------------------------------------------*/ void UN_InitGame() { /* calls UN_InitSector() and sets anything else that needs to be set at the ** beginning of the game (for instance, making sure that there is only one ** player life object in the Player_Dummy list) */ UN_Object *temp; while (Live_Dummy.next_ob != &Live_Dummy) UN_DeleteObject(Live_Dummy.next_ob); while (Player_Dummy.next_ob != &Player_Dummy) { temp=Player_Dummy.next_ob; UN_ObRemove(temp); UN_ObInsert(temp, &Spare_Dummy); } UN_ObInsert(UN_CreateObject(),&Player_Dummy); curmovie=1; AS_ShowMovie(curmovie); StartAsteroids=curmovie*50; StartFood=0; StartProbes=curmovie*10; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); } /*-------------------------------------------------------------------------*/ char UN_PlayGame() { /* Will be called when a sector has been started, either ** after UN_InitGame() or by a game having been paused in mid ** sector, then unpaused. */ unsigned long ticksleft, nextupdate = FE_Set(); /* how many ticks left until next update, and the time of the next update, ** encoded in a way meaningful to FE and AI */ while (1) { probes_exist = 0; if (User->shield <= 0) { AS_PlayFX(FX_DIE); if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } /* UN_NewLife() returns 1 if no lives left for the player */ for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy;) { tobj = curobj->next_ob; if (curobj->shield <= 0) UN_DeleteObject(curobj); /* is this the only bit that removes the dead ? Or is it just a tidy-up ? ** I ask because surely this *should* be done at the point where the shields ** *became* <=0 ? */ /* No. When the shields become <=0, there is one frame where the FE displays ** the object dying. On the *next* frame, the object is removed. */ /* Only a single frame to display that? Perhaps we could introduce simple * 'death animation' objects. Also note that death doesn't automatically * mean total disappearing of an object. An object can also change into * a dead object. This could be implemented in two ways: * Remove dying animate object, and create new dead object on the same place. * or * Change dying object's what and other relevant info into the dead object. * * Further, we may want to determine if this object should be archived at * this point? * * Conclusion: Death needs some work. :) * */ curobj = tobj; } for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy; curobj = curobj->next_ob) if (curobj->shield > 0) UN_CheckObject(curobj); if ((ticksleft = FE_GetTicks(nextupdate)) > 0) AI_DoQueue(ticksleft); nextupdate = FE_Update((User->x) % SUBSIZE, (User->y) % SUBSIZE); /* syskeys that aren't handled below handled here */ if ((SYSKEYS) & 4) FE_ToggleSound(); if ((SYSKEYS) & 2) return 2; if ((SYSKEYS) & 1) return MA_ConfirmQuit(2); if (!(probes_exist)) if (UN_NewSector()) return 1; /* We will probably want to change these conditions. */ /* This would be an ideal place to put a possible call ** to UN_ReSeed() if there are too few or too many objects. */ } } /* Return codes for UN_PlayGame: 0 = quitting, 1 = game over, 2 = paused */ -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From compuserve.com!71044.2164 Wed Oct 25 09:41:32 1995 Return-Path: <71044.2164@compuserve.com> Received: from dub-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t88tN-000fJXC; Wed, 25 Oct 95 09:41 PDT Received: by dub-img-5.compuserve.com (8.6.10/5.950515) id MAA23067; Wed, 25 Oct 1995 12:35:46 -0400 Date: 25 Oct 95 12:28:39 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Directors Subject: main.c, revised Message-ID: <951025162839_71044.2164_GHI94-1@CompuServe.COM> ---------- Forwarded Message ---------- From: Martijn Faassen, INTERNET:Martijn.Faassen@phil.ruu.nl TO: ag universe, INTERNET:AG-UNIVERSE@ALNILAM.KRL.CALTECH.EDU DATE: 10-24-95 1:25 PM RE: main.c, revised Sender: faassen@phil.ruu.nl Received: from alnilam.krl.caltech.edu by dub-img-2.compuserve.com (8.6.10/5.950515) id PAA28389; Tue, 24 Oct 1995 15:33:08 -0400 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t7p7w-000fJtC; Tue, 24 Oct 95 12:35 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.7.1/8.6.12) with ESMTP id UAA21883 for ; Tue, 24 Oct 1995 20:29:31 +0100 (MET) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.7.1/8.6.12) id UAA19770 for ag-universe@alnilam.krl.caltech.edu; Tue, 24 Oct 1995 20:29:29 +0100 (MET) From: Martijn Faassen Message-Id: <199510241929.UAA19770@laurel.stud.phil.ruu.nl> Subject: main.c, revised To: ag-universe@alnilam.krl.caltech.edu (ag universe) Date: Tue, 24 Oct 1995 20:29:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit /***************************************************************************\ * Alife Game - main.c code file * * ------------------------------------------------------------------------- * * Copyright (C) 1995 Us. All Rights Reserved. * * ------------------------------------------------------------------------- * * Created by: Adrian Tymes * * Last Revised: October, 1995 * * By: Martijn Faassen * * Version #: 0.052 * \***************************************************************************/ /* main.c is now compilable, except for quite a few #defines */ #include "alife.h" /* used dummy alife.h to testcompile */ #include "universe.h" /* test compilation, commented out #include "fe.h" #include "as.h" */ /* Description: * #defines of button boundaries. * ULX, ULX : top left corner x and y coordinates * LRX, RLY : botton right corner x and y coordinates * all on 0-1023, 0-767 screen */ /* "New Game" */ #define NEW_ULX 200 #define NEW_ULY 150 #define NEW_LRX 407 #define NEW_LRY 305 /* "Load Game" */ #define LOAD_ULX 616 #define LOAD_ULY 150 #define LOAD_LRX 823 #define LOAD_LRY 305 /* "Save Game" * NOTE: this button is disabled unless the game is paused */ #define SAVE_ULX 616 #define SAVE_ULY 306 #define SAVE_LRX 823 #define SAVE_LRY 461 /* "Continue Game" * NOTE: this button is disabled unless the game is paused */ #define CONT_ULX 200 #define CONT_ULY 306 #define CONT_LRX 407 #define CONT_LRY 461 /* "Replay Movie" * When game is not paused, this button becomes "Show Background Story" */ #define REP_ULX 408 #define REP_ULY 150 #define REP_LRX 615 #define REP_LRY 305 /* "Instructions" */ #define INST_ULX 408 #define INST_ULY 306 #define INST_LRX 615 #define INST_LRY 461 /* "Options" */ #define OPT_ULX 200 #define OPT_ULY 462 #define OPT_LRX 407 #define OPT_LRY 617 /* "Credits" */ #define CRED_ULX 408 #define CRED_ULY 462 #define CRED_LRX 615 #define CRED_LRY 617 /* "Quit" */ #define QUIT_ULX 616 #define QUIT_ULY 462 #define QUIT_LRX 823 #define QUIT_LRY 617 /* "Yes" button has the same boundaries as the main menu's "Options" button, * while "No" has the same boundaries as the main menu's "Quit" button. */ /* "Yes" */ #define YES_ULX OPT_ULX #define YES_ULY OPT_ULY #define YES_LRX OPT_LRX #define YES_LRY OPT_LRY /* "No" */ #define NO_ULX QUIT_ULX #define NO_ULY QUIT_ULY #define NO_LRX QUIT_LRX #define NO_LRY QUIT_LRY /* Description: * Returns TRUE only if coordinates x, y are within boundaries a,b,c,d */ #define UN_Within(x,y,a,b,c,d) ((x>a)&&(xb)&&(y Movie numbers would be more generic if we didn't make any assumptions * about a level structure. To make the game really extensible we could even * come up with a movie linked list instead. */ short curmovie; /* Description: * This function is called when a game is loaded from the main menu. * Comments: * There may be a game paused when this function is called, should be * kept in mind when writing it. */ void MA_LoadGame() { /* TO BE WRITTEN */ } /* Description: * This function is called when a game is saved from the main menu, which * is only possible when the game is paused first. */ void MA_SaveGame() { /* TO BE WRITTEN */ } /* Description: * Calls up the in-game modifiable options menu. This will only relate * to those options which are similar across all platforms, since this is * a MA_ routine, although it will set several variables that FE will use. * Comments: * Many options will be possible, especially for universe and alife. * This will therefore require careful thought. */ void MA_Options() { /* TO BE WRITTEN */ } /* Description: * This function presents a dialog that prompts the user to confirm that * the user wants to quit the game. If the user confirms, this function * returns 0, otherwise it returns the input parameter. * Comments: * FE_PointerStatus is assumed to update the pointer's screen * representation. */ short MA_ConfirmQuit(short mode) { char b1, b2; short x, y; /* commented out for compilability check FE_DisplayScreen(CONFIRMQUITDIALOG); */ while (1) { b1 = 0; while (!b1) { FE_PointerStatus(&x, &y, &b1, &b2); /* This also updates the pointer's screen representation, right? */ } if (UN_Within(x, y, YES_ULX, YES_ULY, YES_LRX, YES_LRY)) return 0; else if (UN_Within(x, y, NO_ULX, NO_ULY, NO_LRX, NO_LRY)) return mode; } } /* Description: * - Initializes tables * - Initializes front end (displays error if unable to) * - Initializes sound (but this may be done in front end already) * - Shows intro movie * - Handles main menu */ main() { short go, x, y; /* there used to be a variable memget here, but it wasn't used * (and 'void' variable declarations GCC can't cope with). Removed it * */ char b1, b2; /* Initialize tables */ UN_InitTable(); /* Initializes front end */ if (go = FE_InitSystem()) { FE_DisplayError(go); exit(); } /* NOTE: following can be erased if sound is already initialized in the * front end. * Commented it out for now */ /* Initializes sound driver */ /* if (go = AS_InitSound(SoundDriver)) { printf("Could not init sound, error code=%i\n", go); exit(); } */ /* show intro movie */ FE_ShowMovie(INTRO); go = 1; /* * from here on, go contains the game's state: * 0=quitting * 1=main menu * 2=paused */ while (go) { if (go == 1) { curmovie = 0; FE_DisplayScreen(MAINMENU); } else { FE_DisplayScreen(PAUSEMENU); } b1 = 0; while (!b1) { FE_PointerStatus(&x, &y, &b1, &b2); } /* This also updates the pointer's screen representation, right? */ /* if new game button is pressed */ if (UN_Within(x, y, NEW_ULX, NEW_ULY, NEW_LRX, NEW_LRY)) { /* initialize game */ UN_InitGame(); /* start game */ go = UN_PlayGame(); } else /* if load game button is pressed */ if (UN_Within(x, y, LOAD_ULX, LOAD_ULY, LOAD_LRX, LOAD_LRY)) { /* load game dialog */ MA_LoadGame(); go = 2; } else /* if game is paused and save game button is pressed */ if ((go == 2) && (UN_Within(x, y, SAVE_ULX, SAVE_ULY, SAVE_LRX, SAVE_LRY))) { /* save game dialog */ MA_SaveGame(); } else /* if game is paused and continue game button is pressed */ if ((go == 2) && (UN_Within(x, y, CONT_ULX, CONT_ULY, CONT_LRX, CONT_LRY))) { /* resume game */ go = UN_PlayGame(); } else /* if game is paused and replay movie button is pressed */ if ((go == 2) && (UN_Within(x, y, REP_ULX, REP_ULY, REP_LRX, REP_LRY))) { /* replay last movie seen */ FE_ShowMovie(curmovie); } else /* if instructions button is pressed */ if (UN_Within(x, y, INST_ULX, INST_ULY, INST_LRX, INST_LRY)) { /* instructions movie is shown * Should this be a movie? Aren't scrollable * pages with text & graphics nicer? Or perhaps our * movie interface will be able to handle that kind of * stuff.. */ FE_ShowMovie(INSTRUCTIONS); } else /* if options button is pressed */ if (UN_Within(x, y, OPT_ULX, OPT_ULY, OPT_LRX, OPT_LRY)) { /* enter options menu structure */ MA_Options(); } else /* if credits button is pressed */ if (UN_Within(x, y, CRED_ULX, CRED_ULY, CRED_LRX, CRED_LRY)) { /* show credits movie */ FE_ShowMovie(CREDITS); } else /* if quit button is pressed */ if (UN_Within(x, y, QUIT_ULX, QUIT_ULY, QUIT_LRX, QUIT_LRY)) { /* show quit dialog */ go = MA_ConfirmQuit(go); } } /* end of WHILE loop */ /* show exit movie */ FE_ShowMovie(OUTRO); /* prepare game for shutdown */ UN_DeInitGame(); FE_DeInitSystem(); /* Bye! */ } -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From compuserve.com!71044.2164 Wed Oct 25 09:41:36 1995 Return-Path: <71044.2164@compuserve.com> Received: from dub-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t88tQ-000fJbC; Wed, 25 Oct 95 09:41 PDT Received: by dub-img-5.compuserve.com (8.6.10/5.950515) id MAA23099; Wed, 25 Oct 1995 12:35:49 -0400 Date: 25 Oct 95 12:29:08 EDT From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Directors Subject: universe.h revised version Message-ID: <951025162908_71044.2164_GHI94-2@CompuServe.COM> ---------- Forwarded Message ---------- From: Martijn Faassen, INTERNET:Martijn.Faassen@phil.ruu.nl TO: ag universe, INTERNET:AG-UNIVERSE@ALNILAM.KRL.CALTECH.EDU DATE: 10-24-95 1:25 PM RE: universe.h revised version Sender: faassen@phil.ruu.nl Received: from alnilam.krl.caltech.edu by dub-img-2.compuserve.com (8.6.10/5.950515) id PAA27943; Tue, 24 Oct 1995 15:30:45 -0400 Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0t7p7E-000fJsC; Tue, 24 Oct 95 12:34 PDT Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.7.1/8.6.12) with ESMTP id UAA21749 for ; Tue, 24 Oct 1995 20:28:28 +0100 (MET) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.7.1/8.6.12) id UAA19762 for ag-universe@alnilam.krl.caltech.edu; Tue, 24 Oct 1995 20:28:26 +0100 (MET) From: Martijn Faassen Message-Id: <199510241928.UAA19762@laurel.stud.phil.ruu.nl> Subject: universe.h revised version To: ag-universe@alnilam.krl.caltech.edu (ag universe) Date: Tue, 24 Oct 1995 20:28:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit /* Universe header version 0.52, copyright (c) 1995 us * Last modified October 1995 by Martijn */ /* universe.h is now compilable */ /* on (flat mode) 32 bit machines/OSes UN_coord's size is assumed to be * 32 bits. * (in case we ever want to port this to 64 bit machines :) */ typedef unsigned long UN_coord; /* Description: * #defines for UN_Object->what * Comments: * All animate UN_Objects are <= MISSILE * (assuming BULLET exhibits no behaviour, just goes on momentum) */ #define PLAYER 0 #define PROBE 1 #define SUPPLY 2 #define MISSILE 3 #define BULLET 4 #define ASTEROID 5 #define UF_EGG 6 #define F_EGG 7 #define D_EGG 8 #define D_PLAYER 9 #define D_PROBE 10 #define D_SUPPLY 11 #define UNMOVABLE 12 #define SPECIAL 13 #define STICKY 14 /* more #defines */ /* Description: * SUBSIZE: size of a subsector in basic distance units. * SUBPOWER = log(base2) (SUBSIZE) * Intended use: floor(z / SUBSIZE) == z >> SUBPOWER; the second is faster */ #define SUBSIZE 67108864 #define SUBPOWER 26 /* Description: * Two times Pi, for table initialisation.*/ #define TWOPI 6.2831853 /* Description: * Maximum thrust possible for probe * Comments: * WARNING: currently completely arbitrary value, not yet * checked for. Only to give size of ThrustCost[] */ #define MAX_THRUST 100 /* Description: * number of subsectors */ #define NUMSUBS 64 /* Description: * Number of UN_Objects that we allocate at boot-up. * Comments: * Maybe this should be set by the configuration instead? This would * necessitate something (probably FE) being run before UN_InitTable() */ #define STARTOBJECTS 100 /* Description: * Maximum sizes of X, Y values * ( = SUBSIZE * NUMSUBS - 1 ) * This is if unsigned long is 32 bits long */ #define MAX_X (unsigned long) 4294967295 #define MAX_Y (unsigned long) 4294967295 /* Description: * Maximum size of bounding box (equal to subsector) */ #define MAX_BBSIDE SUBSIZE /* standard UN_Object definition follows */ /* Explanation of structure: typedef struct { unsigned long x, y: location of object long velx, vely: movement vector (needs to be signed) picture *pic: picture for FE and AS unsigned long what: what the object is: PLAYER - player PROBE - probe ASTEROID - asteroid BULLET - bullet (aka: brain-dead missile) MISSILE - missile (aka: homing bullet) UF_EGG - unfertilized egg F_EGG - fertilized egg D_EGG - dead egg D_PLAYER - dead player D_PROBE - dead probe SUPPLY - supply ship D_SUPPLY - dead supply ship UNMOVABLE - unmovable object SPECIAL - special object STICKY - sticky brick; just like asteroid except that two sticky bricks stick together on collision long facdir: facing direction 0...255 (needs to be signed) PLAYER PROBE SUPPLY BULLET MISSILE: for navigation PLAYER PROBE SUPPLY?: for firing every object: for animations, for example after collision objects may perhaps turn - or perhaps not long mass: mass of object (needs to be signed for momentum computations) NOTE: mass should *never* be less than or equal to zero!! (and mass shouldn't be too low either) PLAYER PROBE SUPPLY BULLET MISSILE: thrust needs this every object: collision needs this unsigned long bboxside: length of side of bounding box every object: collision needs this long shield: currently remaining shield of object (needs to be signed) every object: if shield <= zero then the object dies What happens upon death: PLAYER -> D_PLAYER PROBE -> D_PROBE ASTEROID -> breaks into smaller asteroids or vanishes BULLET -> explodes, then vanishes MISSILE -> explodes, then vanishes UF_EGG -> D_EGG F_EGG -> D_EGG D_EGG -> vanishes D_PLAYER -> vanishes D_PROBE -> vanishes SUPPLY -> D_SUPPLY D_SUPPLY -> vanishes UNMOVABLE -> vanishes (or may be indestructable?) SPECIAL -> depends on what we do with this STICKY -> breaks into smaller sticky bricks or vanishes long energy: currently remaining energy of object (needs to be signed) can be used for navigation/firing by animate objects, and is used to denote nutricious value for inanimate objects PLAYER PROBE MISSILE SUPPLY: used for thrust PLAYER PROBE SUPPLY(?): for firing weapons PLAYER PROBE: to lay an egg, and to fertilize an egg UF_EGG: energy may decay slowly; also nutricious value F_EGG: energy is invested in properties; also nutricious value D_PLAYER D_PROBE D_SUPPLY D_EGG ASTEROID STICKY UNMOVABLE: nutricious value unsigned long age: Frames since creation or last "what" change - probes may use age to base actions on - eggs can hatch at a certain time after fertilisation - certain weapons may explode after a certain time - nutricious value (energy) of dead objects may degenerate with age - statistical purposes Now for the shared memory with extra non generic object information: union { struct { UN_Object *target: current target of object long thrust: thrust power of object long turn: turn speed of object genotype *gtype: pointer to genotype of object - alife stuff weapon *wlist: pointer to the current weapon in the weapon list of this object - system needs to be refined later, but whatever this points to will be fired if the object fires action actions: virtual keypresses done by this probe } animate; (used by PLAYER, PROBE, and SUPPLY) struct { long damage: explosive force of object long type: type of explosion (only contact-damage is supported right now) } bullet; (used by BULLET only) That is, MISSILE should have thrust and turn, just like a normal probe. It should have a type of explosion as well. So a seperate missile struct in the shared memory may be necessary. (perhaps another struct for 'special' stuff, like food and eggs) } extra; UN_Object *next_hash: pointer to next object in list UN_Object **prev_hash: pointer to pointer at this object, **(ob->prev_hash)=ob if (ob!=first object on its sector list) *(ob->prev_hash)= previous_ob->next_hash else *(ob->prev_hash)= sector[ob->x >> SUBSIZE][ob->y >> SUBSIZE] If you're confused by this, UN_Shift() should clear up the way object->prev_hash, object->next_hash, objects, and sector[][] are used. Note that this is only for objects in the objects list. There may be other objects that are on completely seperate lists (weapon lists, for instance?) UN_Object *next_ob, *prev_ob: Used for objects and spares linked lists in a similar manner as next_hash and prev_hash; see UN_DeleteObject() for details on this and spares. . Expanded {next,prev}_ob to be a fully linked list 'cos it's useful for target switching {and not used v.often so speed less important than for {next,prev}_hash} } UN_Object; */ /* Condensed: */ /* I messed around with this structure for a long time before I could * get it to compile properly. * * One trick was adding 'struct' keywords in front of the UN_Object fields * in this struct. Things would compile, however with warnings of improper * type assignments, as now some functions assign 'UN_Object' to * 'struct UN_Object'. * * Another way to get it to compile was to rename the entire struct into * something like Temp_Object, and then place * 'typedef struct Temp_Object UN_Object' in front of it all. * But, this came up with bugs, the compiler complained it didn't know the * size of the thing anymore. * * Finally I solved it all with a cheap hack; the define following * makes everything compilable.. * It isn't very beautiful, and if anybody knows a better way, * I'm all ears. */ /* WARNING: very cheap hack, but works */ #define UN_Object struct UN_Object UN_Object { UN_coord x, y; long velx, vely; picture *pic; long facdir, shield, energy, mass; unsigned long what, bboxside, age; union { struct { UN_Object *target; long thrust,turn; genotype *gtype; weapon *wlist; action actions; } animate; struct { long damage, type; } bullet; } extra; UN_Object *next_hash, **prev_hash; UN_Object *next_ob, *prev_ob; }; /* Description: * Live_Objects points to the start of the linked list containing * all UN_Objects in play. * Spare_Objects points to allocated UN_Objects not currently being * used. (these are reusable) * Sectors contains the subsector lists of objects. * Player_Objects points to the start of the linked list with all * objects owned by the player (? not sure if this was the intention ) */ UN_Object *Live_Objects, *Spare_Objects, *Player_Objects; UN_Object *Sectors[NUMSUBS][NUMSUBS]; UN_Object *User; /* pointer to current player's probe */ char curwhat; /* current what the object is */ long probes_exist; /* (how many) probes still exist */ long curthrust; /* current thrust */ long tempx, tempy; /* temporary subsector holders */ long subx, suby; /* more temporary subsector holders */ float UN_sin[256], UN_cos[256]; /* precomputed sin and cos lookup tables */ UN_Object *curobj; /* pointer to UN_Object currently being checked */ UN_Object *tobj; /* a temporary UN_Object pointer holder */ long curpic; /* current picture number for UN_Object */ long xh,txh,ttxh,dx,yh,tyh,ttyh,dy; /* variables for collision detection */ long StartAsteroids,StartFood,StartProbes; /* how many objects of each type to create at the beginning of the game */ UN_Object Dummies[NUMSUBS][NUMSUBS]; UN_Object Live_Dummy; UN_Object Spare_Dummy; UN_Object Player_Dummy; /* dummy objects - do not alter these outside the UN_ routines */ /* current picture number = * facing (0-255) + THRUSTPIC + BRAKEPIC + TARGETPIC */ #define THRUSTPIC 256 #define BRAKEPIC 512 #define TARGETPIC 1024 /* ** I'm sure we can't afford 1024 pictures per UN_Object (type) ? ** ** And we won't: 256 pictures (maximum) for each of the facing directions, ** with the appropriate "thrusting" picture overlaid if (picture number)&256, ** similar for braking and targetting; especially targetting since that would ** only necessitate placing a non-facing-specific crosshair (or similar) on ** top of the sprite. In addition, similar types of objects would share ** their pictures (for instance, all of one type of asteroid, all of one ** species of probe, etc.). And if we can't afford 256 pictures per object ** type, then use the same picture for multiple facings: if we only want 16 ** pictures per object type, facings 0-15 would share the same picture, as ** would facings 16-31, and so on. Also, note that braking and thrusting ** will never be displayed at the same time, since the universe code won't ** allow an object to thrust and brake simultaneously. */ #define SYSKEYS User->extra.animate.actions /* User always points to the current player's ship, and system keys will * always be passed to the universe (as opposed to main/menu) part of the game * by that object's actions */ /* function prototypes */ /* Since this is the universe.h file, should the various FE, AI and * AL (I'm not clear on the difference between AI and AL here) functions * be declared here, or in their seperate .h files instead? * (I propose we leave them in here now, but move them out when the front * end and alife parts of the game become compilable */ action FE_GetKeys(); action AI_GetKeys(UN_Object *obj); void AI_Interrupt(UN_Object *obj, long type); /* need #define for THRUST_FAIL and BRAKE_FAIL types * And also various other possible interrupts, like COLLISION, etc, * or HEAVY_ENERGY_LOSS, or whatever else is easy to notice in universe */ void AS_SetPic(picture *pic,long type); /* handles animation */ /* long thrustcost[MAX_LONG_INT]; lookup for thrustcost /* A table of longs, long long?? changed it*/ long ThrustCost[MAX_THRUST]; /* lookup for thrustcost */ long FE_Set(); void AS_PlayFX(long type); void AS_ShowMovie(long number); long FE_GetTicks(long NextUpdate); void AI_DoQueue(long FE_TicksLeft); long FE_Update(long CenterSubsectorX, long CenterSubsectorY); /* removed passing of Sectors (FE should probably know this * anyway), besides I'm tired and can't get it to pass the right * pointer, somehow. :) */ void FE_ToggleSound(); short MA_ConfirmQuit(short mode); void AL_InitPlayerGenome(UN_Object *player); void AL_InitAsteroidGenome(UN_Object *rock); void AL_InitProbeGenome(UN_Object *thing); unsigned long UN_Random(unsigned long max); void UN_CheckObject(UN_Object *obj); void UN_Shift(long sectx, long secty, UN_Object *obj); void UN_InsertObject(long sectx, long secty, UN_Object *obj); UN_Object *UN_CreateObject(); void UN_DeleteObject(UN_Object *obj); void UN_InitTable(); void UN_ReSeed(); void UN_InitSector(); char UN_NewSector(); void UN_InitGame(); short UN_NewLife(); char UN_PlayGame(); void UN_DeInitGame(); void UN_ObInsert(UN_Object *ob, UN_Object *dummy); void UN_ObRemove(UN_Object *ob); void UN_HashInsert(UN_Object *ob, UN_Object **list); void UN_HashRemove(UN_Object *ob); void UN_Animate(UN_Object *obj); void UN_Movement(UN_Object *obj); void UN_CreatePlayer(UN_coord x, UN_coord y); void UN_CreateAsteroid(); void UN_CreateFood(); void UN_CreateProbe(); int UN_Collision(UN_Object *which); -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From charles Sat Nov 11 23:51:42 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tEXCU-000fIzC; Sat, 11 Nov 95 23:51 PST Received: by altair.krl.caltech.edu; (5.65v3.0/1.1.8.2/14Apr95-0417PM) id AA15461; Sat, 11 Nov 1995 23:48:03 -0800 Message-Id: <9511120748.AA15461@altair.krl.caltech.edu> Subject: [ File transmission ] To: ag-directors Date: Sat, 11 Nov 1995 23:48:03 -0800 (PST) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5186 Path: nntp-server.caltech.edu!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!news-out.internetmci.com!internetMCI!newsfeed.internetmci.com!solaris.cc.vt.edu!jsciv From: obrien@netcom.com (No parking EXCEPT FOR BOB) Newsgroups: comp.sys.ibm.pc.games.announce,comp.sys.ibm.pc.games.strategic Subject: CDDNA: Shareware Strategy Game - and Genetic Algorithm Laboratory Followup-To: comp.sys.ibm.pc.games.strategic Date: 8 Nov 1995 16:29:39 GMT Organization: for Oidian Systems, San Jose, California Lines: 103 Sender: obrien@netcom.com (No parking EXCEPT FOR BOB) Approved: jsciv@vt.edu Message-ID: Reply-To: obrien@netcom.com (No parking EXCEPT FOR BOB) NNTP-Posting-Host: discus.ise.vt.edu Summary: Limited release, version 1.0, COMMENTS REQUESTED Keywords: Genetic Algorithms No Cheats Network Multiplayer Evolve Your Own Opponents Trade CPs with Friends Status: OR Originator: jsciv@discus.ise.vt.edu Xref: nntp-server.caltech.edu comp.sys.ibm.pc.games.announce:1366 comp.sys.ibm.pc.games.strategic:123976 ======= Game description: ======= CDDNA runs on Microsoft Windows. Testing on Win95 has been less extensive than on 3.x CDDNA bears some comparisons to Diplomacy, to Stratego, and to Risk. CDDNA is the first in a planned family of Genetic Algorithm programs. CDDNA was inspired in part by the above mentioned games and many more. Among the inspirations for the Computer Player sections of CDDNA are games like Civilization, Master of Orion, and others where the CPs are not bound by the same rules as human players. These games are often accuesed of "cheating," and CDDNA will have none of this. Using the included programming language, CDDNA players will have the option of writing their own CPs. These, along with all CPs included with the game, can be used in the Evolution Laboratory section to evolve more and potentially better CPs than even the game's creators have written. ======= Release Note: ======= This is an "early feedback" release. We want you to try our game if you are at all interested, but it is very important to us during this early phase to receive feedback, good and bad. Obviously, registration fees are our FAVORITE kind of feedback, and registration information is included in the extensive built-in help. Feedback is welcome, to the contact points noted in the help, and also to the account originating this posting, (during the limited release period of November, 1995.) This is being called a "1.0" release, because we believe it to be very stable. It has passed serious testing, including a Beta program, but our standards for Beta testing aren't like those of certain large companies - we think that's a good thing for YOU, but we also are aware of the possibility that there are still things that should be fixed right away. We intend to be very responsive with a "1.1" release, IF reports warrant it. We hope, but are not certain, that this version is good enough to encourage everyone who gets it to distribute it freely. However, at this time, we are asking that you NOT do so. IF it should prove to have problems, we WANT to fix them right away, BEFORE lots and lots of people see it. Obviously, anyone you know who WOULD be happy to send FAST feedback is someone we DO want you to give it to. The Registered version IS expected to be ready to ship on the date shown below. ====== Press Release: ====== Computer Game uses Genetic Algorithms to Improve Computer Opponents while you use it. San Jose, CA - Oidian Systems has announced the release of a Windows shareware computer strategy game which uses genetic algorithms to improve the performance of the computer players. "Cloak, Dagger and DNA" contains, in addition to the game, an Evolution Laboratory which allows the user to control a gene pool of computer players, and set various parameters while running an evolution engine. This multiplayer game allows human players to play interactively using a local area network. The computer players can be hand coded, evolved, and traded with other players. The shareware version contains everything needed to play and evolve players, including extensive on-line help files, and a handful of computer player gene files. The registered version, available after 15 November 1995, contains a scenario editor which allows changing the playing map, starting positions and player strengths, and modification of some of the game rules. Different environments and game rules can be constructed for experimenting with evolving different computer player capabilities. ====== How to Obtain: ====== For the shareware version, browse to: http://www.obob.net/~obrien/oidian ftp from: ftp://www.obob.net/users/obrien/oidian/cddna.zip ** For a LIMITED time ONLY, E-mail requests may be sent to: ** obrien@netcom.com ** Explicitly request the file "cddna.uue" ** E-mail recipients MUST uudecode and unzip. ** Encoded file is ~400K bytes. ** E-mail offer EXPIRES at the end of November, 1995 For more info send e-mail to the author if this message. -- From compuserve.com!71044.2164 Mon Nov 20 23:31:23 1995 Return-Path: <71044.2164@compuserve.com> Received: from dub-img-1.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tHnAH-000fKKC; Mon, 20 Nov 95 23:30 PST Received: by dub-img-1.compuserve.com (8.6.10/5.950515) id CAA21215; Tue, 21 Nov 1995 02:23:17 -0500 Date: 21 Nov 95 02:22:07 EST From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Universe Cc: AG-Directors Subject: Main.c 0.53 Message-ID: <951121072207_71044.2164_GHI35-2@CompuServe.COM> /***************************************************************************\ * Alife Game - main.c code file * * ------------------------------------------------------------------------- * * Copyright (C) 1995 Us. All Rights Reserved. * * ------------------------------------------------------------------------- * * Created by: Adrian Tymes * * Last Revised: 11/20/95 * * By: Adrian Tymes * * Version #: 0.053 * \***************************************************************************/ /* main.c is now compilable, except for quite a few #defines */ #include "alife.h" /* used dummy alife.h to testcompile */ #include "universe.h" #include "fe.h" #include "as.h" /* Description: * #defines of button boundaries. * ULX, ULX : top left corner x and y coordinates * LRX, RLY : botton right corner x and y coordinates * all on 0-1023, 0-767 screen */ /* "New Game" */ #define NEW_ULX 200 #define NEW_ULY 150 #define NEW_LRX 407 #define NEW_LRY 305 /* "Load Game" */ #define LOAD_ULX 616 #define LOAD_ULY 150 #define LOAD_LRX 823 #define LOAD_LRY 305 /* "Save Game" * NOTE: this button is disabled unless the game is paused */ #define SAVE_ULX 616 #define SAVE_ULY 306 #define SAVE_LRX 823 #define SAVE_LRY 461 /* "Continue Game" * NOTE: this button is disabled unless the game is paused */ #define CONT_ULX 200 #define CONT_ULY 306 #define CONT_LRX 407 #define CONT_LRY 461 /* "Replay Movie" * When game is not paused, this button becomes "Show Background Story" */ #define REP_ULX 408 #define REP_ULY 150 #define REP_LRX 615 #define REP_LRY 305 /* "Instructions" */ #define INST_ULX 408 #define INST_ULY 306 #define INST_LRX 615 #define INST_LRY 461 /* "Options" */ #define OPT_ULX 200 #define OPT_ULY 462 #define OPT_LRX 407 #define OPT_LRY 617 /* "Credits" */ #define CRED_ULX 408 #define CRED_ULY 462 #define CRED_LRX 615 #define CRED_LRY 617 /* "Quit" */ #define QUIT_ULX 616 #define QUIT_ULY 462 #define QUIT_LRX 823 #define QUIT_LRY 617 /* "Yes" button has the same boundaries as the main menu's "Options" button, * while "No" has the same boundaries as the main menu's "Quit" button. */ /* "Yes" */ #define YES_ULX OPT_ULX #define YES_ULY OPT_ULY #define YES_LRX OPT_LRX #define YES_LRY OPT_LRY /* "No" */ #define NO_ULX QUIT_ULX #define NO_ULY QUIT_ULY #define NO_LRX QUIT_LRX #define NO_LRY QUIT_LRY /* Description: * Returns TRUE only if coordinates x, y are within boundaries a,b,c,d */ #define UN_Within(x,y,a,b,c,d) ((x>a)&&(xb)&&(y Movie numbers would be more generic if we didn't make any assumptions * about a level structure. To make the game really extensible we could even * come up with a movie linked list instead. */ short curmovie; /* Description: * This function is called when a game is loaded from the main menu. * Comments: * There may be a game paused when this function is called, should be * kept in mind when writing it. */ void MA_LoadGame() { /* TO BE WRITTEN */ } /* Description: * This function is called when a game is saved from the main menu, which * is only possible when the game is paused first. */ void MA_SaveGame() { /* TO BE WRITTEN */ } /* Description: * Calls up the in-game modifiable options menu. This will only relate * to those options which are similar across all platforms, since this is * a MA_ routine, although it will set several variables that FE will use. * Comments: * Many options will be possible, especially for universe and alife. * This will therefore require careful thought. */ void MA_Options() { /* TO BE WRITTEN */ } /* Description: * This function presents a dialog that prompts the user to confirm that * the user wants to quit the game. If the user confirms, this function * returns 0, otherwise it returns the input parameter. * Comments: * FE_PointerStatus is assumed to update the pointer's screen * representation. */ short MA_ConfirmQuit(short mode) { char b1, b2; short x, y; /* commented out for compilability check FE_DisplayScreen(CONFIRMQUITDIALOG); */ while (1) { b1 = 0; while (!b1) { FE_PointerStatus(&x, &y, &b1, &b2); /* This also updates the pointer's screen representation, right? */ } if (UN_Within(x, y, YES_ULX, YES_ULY, YES_LRX, YES_LRY)) return 0; else if (UN_Within(x, y, NO_ULX, NO_ULY, NO_LRX, NO_LRY)) return mode; } } /* Description: * - Initializes tables * - Initializes front end (displays error if unable to) * - Initializes sound (but this may be done in front end already) * - Shows intro movie * - Handles main menu */ main() { short go, x, y; /* there used to be a variable memget here, but it wasn't used * (and 'void' variable declarations GCC can't cope with). Removed it * */ char b1, b2; /* Initialize tables */ UN_InitTable(); /* Initializes front end */ if (go = FE_InitSystem()) { FE_DisplayError(go); exit(); } /* NOTE: following can be erased if sound is already initialized in the * front end. * Commented it out for now */ /* Initializes sound driver */ /* if (go = AS_InitSound(SoundDriver)) { printf("Could not init sound, error code=%i\n", go); exit(); } */ /* show intro movie */ FE_ShowMovie(INTRO); go = 1; /* * from here on, go contains the game's state: * 0=quitting * 1=main menu * 2=paused */ while (go) { if (go == 1) { curmovie = 0; FE_DisplayScreen(MAINMENU); } else { FE_DisplayScreen(PAUSEMENU); } b1 = 0; while (!b1) { FE_PointerStatus(&x, &y, &b1, &b2); } /* This also updates the pointer's screen representation, right? */ /* if new game button is pressed */ if (UN_Within(x, y, NEW_ULX, NEW_ULY, NEW_LRX, NEW_LRY)) { /* initialize game */ UN_InitGame(); /* start game */ go = UN_PlayGame(); } else /* if load game button is pressed */ if (UN_Within(x, y, LOAD_ULX, LOAD_ULY, LOAD_LRX, LOAD_LRY)) { /* load game dialog */ MA_LoadGame(); go = 2; } else /* if game is paused and save game button is pressed */ if ((go == 2) && (UN_Within(x, y, SAVE_ULX, SAVE_ULY, SAVE_LRX, SAVE_LRY))) { /* save game dialog */ MA_SaveGame(); } else /* if game is paused and continue game button is pressed */ if ((go == 2) && (UN_Within(x, y, CONT_ULX, CONT_ULY, CONT_LRX, CONT_LRY))) { /* resume game */ go = UN_PlayGame(); } else /* if game is paused and replay movie button is pressed */ if ((go == 2) && (UN_Within(x, y, REP_ULX, REP_ULY, REP_LRX, REP_LRY))) { /* replay last movie seen */ FE_ShowMovie(curmovie); } else /* if instructions button is pressed */ if (UN_Within(x, y, INST_ULX, INST_ULY, INST_LRX, INST_LRY)) { /* instructions movie is shown * Should this be a movie? Aren't scrollable * pages with text & graphics nicer? Or perhaps our * movie interface will be able to handle that kind of * stuff.. * The universe calls it a "movie". AS, FE, and the * end user may very well call it something else (like * scrolling pages with text and graphics). The key * idea is that the universe doesn't know or care what * happens when it plays a movie; it merely passes * control to the "movie player", which can be configured * for movies or text without having to fiddle with the * universe code. */ FE_ShowMovie(INSTRUCTIONS); } else /* if options button is pressed */ if (UN_Within(x, y, OPT_ULX, OPT_ULY, OPT_LRX, OPT_LRY)) { /* enter options menu structure */ MA_Options(); } else /* if credits button is pressed */ if (UN_Within(x, y, CRED_ULX, CRED_ULY, CRED_LRX, CRED_LRY)) { /* show credits movie */ FE_ShowMovie(CREDITS); } else /* if quit button is pressed */ if (UN_Within(x, y, QUIT_ULX, QUIT_ULY, QUIT_LRX, QUIT_LRY)) { /* show quit dialog */ go = MA_ConfirmQuit(go); } } /* end of WHILE loop */ /* show exit movie */ FE_ShowMovie(OUTRO); /* prepare game for shutdown */ UN_DeInitGame(); FE_DeInitSystem(); /* Bye! */ } From compuserve.com!71044.2164 Mon Nov 20 23:32:37 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-3.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tHnBx-000fKLC; Mon, 20 Nov 95 23:32 PST Received: by arl-img-3.compuserve.com (8.6.10/5.950515) id CAA08466; Tue, 21 Nov 1995 02:25:00 -0500 Date: 21 Nov 95 02:23:30 EST From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Universe Cc: AG-Directors Subject: Universe.c 0.53 Message-ID: <951121072329_71044.2164_GHI35-4@CompuServe.COM> /* Universe code version 0.53, copyright (c) 1995 us * Last modified by Adrian Tymes, 11/20/95 */ /* I haven't checked all of the code closely yet, so this could * definitely be revised further, especially some cleaning up * of redudant comments, etc */ #include /* for sin and cos */ #include /* for definition of NULL */ #include "universe.h" #include "fe.h" #include "as.h" #include "alife.h" /* ** Renamed (more meaningful and also Capitalized for important arrays): ** objects -> Live_Objects ** spares -> Spare_Objects ** sector -> Sectors ** thrustcost ->ThrustCost ** ** *_Objects are all gone now (Sic Transit Gloria Mundi) instead we ** now do all list access *through* the dummy object, e.g. ** Live_Dummy.next_ob is the first live object. ** We could have MACRO's defined for these but do we really need ** them ? */ /* ** Inserts an UN_Object into the specified object list (which ** means Live_Objects, Spare_Objects or Player_Objects at the moment). ** ** Now that this is doubly linked and we have dummies, we no longer need ** pointers to the lists and can access them through the dummies ** themselves . ** ** Assumes that the UN_Object was correctly removed from any ** previous list it belonged to. */ /* Description: * Inserts UN_Object ob as next object of UN_Object dummy, * in a doubly linked list. * Comments: * Assumes that the UN_Object was correctly removed from any * previous list it belonged to. (like the Spare_Objects list) */ void UN_ObInsert(UN_Object *ob, UN_Object *dummy) { ob->prev_ob = dummy; ob->next_ob = dummy->next_ob; dummy->next_ob->prev_ob = ob; dummy->next_ob = ob; } /* ** Removes an UN_Object from whatever object list it belongs to. ** ** Will probably crash if the UN_Object wasn't in one.*/ /* Description: * Removes UN_Object from doubly linked list it belongs to. * Comments: * WARNING: UN_Object has to be in a doubly linked list! */ void UN_ObRemove(UN_Object *ob) { (ob->next_ob)->prev_ob = ob->prev_ob; (ob->prev_ob)->next_ob = ob->next_ob; } /* ** Next two routines are exactly like previous two but act on sector ** lists. */ /* Description: * Inserts an object into a subsector list. * Comments: * Assumes that this object was correctly removed from its previous * subsector list */ void UN_HashInsert(UN_Object *ob, UN_Object **list) { ob->prev_hash = list; ob->next_hash = *list; (*list)->prev_hash = &(ob->next_hash); *list = ob; } /* Description: * Removes object from its subsector list. * Comments: * Object has to be in subsector list! */ void UN_HashRemove(UN_Object *ob) { (ob->next_hash)->prev_hash = ob->prev_hash; *(ob->prev_hash) = ob->next_hash; } /* Description: * Move an UN_Object from one sector list to another. */ void UN_Shift(long sectx, long secty, UN_Object * obj) { /* first remove us from our old list */ UN_HashRemove(obj); /* now insert us at the start of the new list */ UN_HashInsert(obj, &(Sectors[sectx][secty])); } /* initialize starting UN_Objects (as in, we *know* that we'll need at least ** STARTOBJECTS UN_Objects, so let's allocate them while the user expects ** initialization lag) */ /* ** I'm assuming that this gets called exactly once. ** ** That's the current plan. */ /* Description: * Initializes starting UN_Objects. * Comments: * We know we'll need at least STARTOBJECTS Un_Objects anyway, so * let's allocate them while the user expects initialization lag. * Assumed is that this function gets called exactly once. */ void UN_InitTable() { int i; Live_Dummy.prev_ob = &Live_Dummy; /* make a closed doubly-linked list */ Live_Dummy.next_ob = &Live_Dummy; /* with one member */ Spare_Dummy.prev_ob = &Spare_Dummy; /* ditto */ Spare_Dummy.next_ob = &Spare_Dummy; Player_Dummy.prev_ob = &Player_Dummy; /* ditto */ Player_Dummy.next_ob = &Player_Dummy; Live_Objects = &Live_Dummy; Spare_Objects = &Spare_Dummy; Player_Objects = &Player_Dummy; /* I didn't see these initialized or defined elsewhere... */ /* ** The following leaves undefined UN_Objects in the Spare_Objects list, ** UN_InitSector will initialise and move them to Live_Objects ** as things are created. */ tobj = (UN_Object *)malloc(sizeof(UN_Object) * STARTOBJECTS); for (i = 1; i < STARTOBJECTS; i++) { /* Removed & in front of Spare_Objects, is already a pointer */ UN_ObInsert(tobj++, Spare_Objects); } /* now to initialize UN_sin[] and UN_cos[] lookup tables */ for (i = 0; i < 255; i++) { UN_sin[i] = (float) sin((double)i * (double)TWOPI / (double)256.); UN_cos[i] = (float) cos((double)i * (double)TWOPI / (double)256.); /* GNU C (which is probably one of the compilers we will be working with) * expects radians, so I changed it to that. (Since radians are ANSI also) * Also I sprinkled plenty of typecasts all over the thing, to make sure * it doesn't do that wrong. */ } } /* used to insert a new UN_Object into the * objects list and its Sectors[][] list; assumes that nothing critical is * being pointed to only by obj->prev_hash, obj->next_hash, obj->next_ob, or * obj->prev_ob * * Note: I've updated this function but the things it does don't * make a lot of sense 'cos the UN_Objects list and sectors lists * aren't likely to be adjusted at the same time now * we have Spare_Objects. */ /* Description: * Inserts a UN_Object into the objects list and its Sectors[][] list * at the same time. * Comments: * As we are working with Spare_Objects now, this function is probably * obsolete. * Assumes nothing critical is being pointed to by obj->prev_hash, * obj->next_hash, obj->next_ob, and obj->prev_ob. */ void UN_InsertObject(long sectx, long secty, UN_Object *obj) { /* Removed & in front of Live_Objects */ UN_ObInsert(obj, Live_Objects); UN_HashInsert(obj, &(Sectors[sectx][secty])); } /* Description: * - Returns a (new) UN_Object (from the Spare_Objects list, or newly * allocated if none available. * * Comments: * - Don't assume anything about initial conditions of any value in the * UN_Object (including next_ob and prev_ob)! So EVERY value has to be * initialized. * - Doesn't yet include check if there is sufficient memory left! */ UN_Object *UN_CreateObject() { UN_Object *tob; /* formerly this declaration was inside the function, * which isn't possible in ANSI C */ /* There was a bug here, != should be ==, so I corrected this * (if I understand this correctly!) */ if (Spare_Dummy.next_ob == &Spare_Dummy) { /* if there is no spare object left, allocate new object */ return (UN_Object *)malloc(sizeof(UN_Object)); /* WARNING: Include free memory check! */ } else { /* there are still spare objects, so return one */ tob = Spare_Dummy.next_ob; UN_ObRemove(tob); return tob; } } /* Description: * Removes an object in the Live_Objects list from that list, and also * removes it from its Sectors[][] list. * It will then be inserted into the Spare_Objects list, so later the * memory can be reused by a new object. */ void UN_DeleteObject(UN_Object *obj) { UN_ObRemove(obj); UN_HashRemove(obj); UN_ObInsert(obj, &Spare_Dummy); } /* Description: * UN_CheckObject is called for each object each 'tick' */ void UN_CheckObject(UN_Object *obj) { curwhat = obj->what; /* type of UN_Object is stored in curwhat */ curpic = 0; if ((curwhat == BULLET) || (curwhat == MISSILE)) { /* these types have a maximum lifespan set at creation */ (obj->age)--; if (obj->age == 0) (obj->shield) = 0; } else (obj->age)++; /* get keys & virtual keys */ switch (curwhat) { case PLAYER: /* this is the player */ obj->extra.animate.actions = FE_GetKeys(); /* get the real keypresses */ break; /* <<1>> */ case PROBE: /* this is a probe */ probes_exist++; /* count surviving probes */ case MISSILE: /* probe remote control, and standard control routines */ /* get the virtual keypresses from a short AI routine - * real alife work is done elsewhere */ obj->extra.animate.actions = AI_GetKeys(obj); break; /* case SUPPLY */ } /* end of switch(curwhat) */ if (curwhat <= MISSILE) { /* this is an animate UN_Object */ UN_Animate(obj); } /* end if animate */ /* Note that curpic is set in the code that was move to UN_Animate(); ** it might be clearer to move all curpic setting code in that function ** (which for now consists of detecting thrusting and braking) back into ** this function. */ UN_Movement(obj); /* Movement update */ if (User->extra.animate.target == obj) { curpic |= TARGETPIC; } AS_SetPic(obj->pic, curpic | obj->frame); /* <<2>> */ obj->frame++; /* frame, being an unsigned char, should ignore overflow */ } /* ** <<1>> this makes all objects of type PLAYER act in exactly the same ** way...we might want to have some other means of controlling PLAYER ** objects that aren't currently being controlled by the player. */ /* * My assumption was that if we have objects 'owned' by the player but * currently not controlled by the player, then they will have an extra * variable set somewhere 'owned by the player'. (or will be in a special * 'owned by player list') Therefore, their 'what' variable will not * be PLAYER. It is assumed only one such object is around at the * time. (until we create a multiplayer networked version :) * * The PLAYER objects in play all correspond to things using the player's * keypresses for control. The player's bullets, missiles, etc. are of * 'what' BULLET, MISSILE, etc., while the player's objects that are not * currently in play are in the Player_Dummy list. Unless and until we * have more than one player ship in the game at a time, what other objects * does the player own? */ /* ** <<2>> Sets the current picture so FE can just display it if it is visible, ** also allows cycling of colors. ** ** Since AS does not care about facing, I replaced facdir's bits with current ** frame bits. Not many platforms at the moment can support 256 frames of ** animation per sprite, but the capability's there if any platform we port ** to ever does want it. For less frames, the current frame is this number ** mod however many frames desired, which will still cycle through one frame ** of animation per update. Effect overlays (TARGETPIC, etc.) still must be ** accounted for. */ /* Description: * Updates animate objects (turning, thrusting). */ void UN_Animate(UN_Object *obj) { tempx = obj->x >> SUBPOWER; /* store original subsector */ tempy = obj->y >> SUBPOWER; /* corrected to use bit shift */ if (obj->extra.animate.actions & THRUST) { /* forward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx += (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely += (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ curpic = THRUSTPIC; } else { /* not enough energy for thrust */ /* FE call here for thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, THRUST_FAIL); /* <> */ } } /* end of not enough energy code */ } /* end of THRUST code */ else if (obj->extra.animate.actions & BRAKE) { /* backward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx -= (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely -= (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this brake thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ curpic = BRAKEPIC; } else { /* not enough energy for brake thrust */ /* FE call here for brake thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, BRAKE_FAIL); /* "hardware" interrupt */ } } /* end of not enough energy code */ } /* end of BRAKE code - end of THRUST/BRAKE code */ /* * NOTE: we might want to kick out different turn speeds, and use a * standard turnspeed instead for each object */ if (obj->extra.animate.actions & LEFT) { /* turn to the left */ /* <> */ obj->facdir = (obj->facdir - obj->extra.animate.turn) & 0xff; /* <> */ } /* end of LEFT code */ else if (obj->extra.animate.actions & RIGHT) { /* turn to the right */ /* turning to the right, so clockwise, means increasing angle */ obj->facdir = (obj->facdir + obj->extra.animate.turn) & 0xff; } /* end of RIGHT code */ if (curwhat == PLAYER) { if (obj->extra.animate.actions & NEXTTARGET) { /* cycle to next target */ do { do { obj->extra.animate.target = obj->extra.animate.target->next_ob; } while ((ABS(obj->extra.animate.target->x - obj->x) > TARGET_RADIUS) || (ABS(obj->extra.animate.target->y - obj->y) > TARGET_RADIUS)); } while (obj->extra.animate.target != &Live_Dummy); } else if (obj->extra.animate.actions & LASTTARGET) { /* cycle to previous target */ do { do { obj->extra.animate.target = obj->extra.animate.target->prev_ob; } while ((ABS(obj->extra.animate.target->x - obj->x) > TARGET_RADIUS) || (ABS(obj->extra.animate.target->y - obj->y) > TARGET_RADIUS)); } while (obj->extra.animate.target != &Live_Dummy); } } /* Partially fixed targetting code, but it needs to be able to handle * wraparound */ if (obj->extra.animate.actions & FIRE) { /* Added primitive fire code */ if (obj->energy >= obj->extra.animate.wlist->x) { /* if enough energy; cost = prototype's x variable */ UN_Object *temp; temp = UN_CreateObject(); temp->x = obj->x + obj->velx + obj->velx; temp->y = obj->y + obj->vely + obj->vely; /* Two adds are at least as fast as an add and a multiply: x + (2*velx) */ temp->velx = obj->velx; temp->vely = obj->vely; /* We will eventually have to implement fast and slow bullets. */ temp->facdir = obj->facdir; temp->extra.bullet.type = obj->extra.animate.wlist->extra.bullet.type; temp->extra.bullet.damage = obj->extra.animate.wlist->extra.bullet.damage; temp->what = obj->extra.animate.wlist->what; temp->shield = obj->extra.animate.wlist->shield; temp->energy = obj->extra.animate.wlist->energy; temp->mass = obj->extra.animate.wlist->mass; temp->age = obj->extra.animate.wlist->age; temp->bboxside = obj->extra.animate.wlist->bboxside; UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, &Sectors[temp->x >> SUBPOWER][temp->y >> SUBPOWER]); AS_InitializePic(&temp); obj->energy -= obj->extra.animate.wlist->x; } else { /* not enough energy to fire */ /* FE call here for fire fail art/sound, currently none */ if (curwhat == PROBE) { AI_interrupt(obj, FIRE_FAIL); /* "hardware" interrupt */ } } /* end of not enough energy code */ } /* end of FIRE code */ /* need to add in cycle weapon code for PLAYER/PROBE */ /* one possibility: have objects outside of the objects list be the * prototypes for each weapon, with next_hash/prev_hash forming a circular * double-linked list for each object; cycle weapon would then get the next (or * previous) object on that list, while fire would merely make a duplicate of * that weapon into the objects list, editing velocity, position, and (if * needed) target as needed */ /* need to add in eat code for PLAYER/PROBE */ /* need to add in energy to shield code for PLAYER/PROBE/SUPPLY */ /* need to add in breed stuff */ /* need to add in pick up/drop */ /* these last two could merely set flags (for instance, * object->extra.animate.actions & BREED) that could be * checked if the object bumps into another object, since * fertilization and grabbing will only be processed when an * object that is trying to do that comes into contact with * another one */ /* Another possibility for breed/grab/eat is to use the targetting code, * and enable breeding/grabbing/eat at a limited distance, so the probes won't * have to do complicated maneuvering just to grab something..*/ } /* ** <> assuming navigation system with north = 0, clockwise increase ** calculate vector changes */ /* ** <> hardware interrupt for AI, note that hardware interrupt calls ** don't do anything directly; the interrupt is just registered, ** later the interrupt handler will handle it */ /* <> turning to left, so counterclockwise, means decreasing angle ** ** % operator doesn't work here, because when turning left the facdir ** will never rise above 255. Instead code is needed to handle facdir ** < 0. This code will break with turnspeed > 256 :) ** ** I've changed it to use "&" which should work on all 2's compliment ** systems (which I *think* is ANSI for C). ** ** Although it is widely used, 2's compliment is apparently not ANSI C. ** There is a good chance that all of the systems we write this for will ** be 2's compliment, however, so maybe we should check with FE before ** changing this just in case we don't have to. */ /* In general, I suggest we make a list of all the non-ANSI assumptions * we've made. (like size of long, under/overflow, and 2's compliment) * */ /* ** <> code and comments removed ** if (obj->facdir < 0) { ** obj->facdir += 256; ** } ** ** alternatively (if faster?) use: obj->facdir = (256 + (obj->facdir - ** obj->extra.animate.turn)) % 256 */ /* Description: * Called when the player's probe has just died. This routine determines * if the player has any 'lives' left. If so, it turns one of the player's * 'life' objects into the player object, sets whatever variables that are * needed for it to be the player, then returns 0. If the player is * out of lives, it returns 1, which the main play lookps takes as a signal * to end the game. * Comments: * No parametres should be needed, since the object and subsector lists * are global. */ short UN_NewLife() { /* this depends on how we implement 'lives'. An idea I've been toying with * is to let all lives be either eggs, or even active probes. When the player * dies the player owned eggs/probes are checked, and one is picked to * reincarnate the player. * Also, a nice animation would be required (egg hatching, whatever) * in this case. */ if (Player_Dummy.prev_ob == &(Player_Dummy)) return 1; else { UN_CreatePlayer(User->x,User->y); /* default initial placement */ return 0; } } /* * Does the player have to be 'object #0' 'genotype #0'? Do we indeed still * have numbered objects at all? * * As of now, we are not using numbered objects. */ /* Description: * Initializes a sector (including "dummy" objects at the end of subsector * lists), populates it with food sources, asteroids, and probes, then * places the player somewhere in the sector. */ void UN_InitSector() { int i, j; /* Tidy Object lists by just dumping any Live_Objects onto * Spare_Objects. (This leaves inactive Player_Objects untouched.) */ while((tobj = Live_Dummy.next_ob) != &Live_Dummy) { UN_ObRemove(tobj); UN_ObInsert(tobj, &Spare_Dummy); } /* This could be done as a single transfer but I'm too tired */ /* Just blank the hash tables. */ for(i = 0; i < NUMSUBS; i++) { for(j = 0; j < NUMSUBS; j++) { Sectors[i][j] = &(Dummies[i][j]); Dummies[i][j].prev_hash = &(Sectors[i][j]); Dummies[i][j].next_hash = Sectors[i][j]; /* next_hash shouldn't ever be referenced but this may be safer */ } } UN_CreatePlayer(0,0); /* As good a place as any to start :) */ for(i = 0; i < StartAsteroids; i++) { UN_CreateAsteroid(); } for(i = 0; i < StartFood; i++) { UN_CreateFood(); } for(i = 0; i < StartProbes; i++) { UN_CreateProbe(NULL); /* This isn't the only place a genome could come from. This is where 'seed' ** genomes arise (from the archive of previous heroes ? (In which case the ** archiving routines might eventually fall into a different function heading ** AR_* ?)). */ /* True, however, UN_CreateProbe() will always need to have a genome for ** the created probe, so I've moved the genome creation call to inside the ** UN_CreateProbe() routine. */ /* But genome creation depends on universe circumstances. That is, if * two probes cooperate to lay an egg, the genome creaton code needs to * do something entirely different than when a random probe is thrown * into the universe, or a nonrandom probe is retrieved from the archives. * */ /* I've changed a call to include a parameter for AI so it can tell how the * probe was created, NULL being the code for "random/no parent". */ } /* ** ... ** Insert any other object type you want to start with here. */ } /* Description: * Pulls a player object off the waiting stack (Player_Dummy) and sets it up * as the active player. If there aren't any on the stack, behaviour * is undefined (might ultimately create a default one but I don't yet * know enough to say what 'default' is). * Comments: * Default: this procedure should not be called if * Player_Dummy.prev_ob == &(Player_Dummy). * This implies something like UN_CreatePlayerLife. */ void UN_CreatePlayer(UN_coord x, UN_coord y) { User = Player_Dummy.prev_ob; /* Use last craft from list (e.g. FIFO) * as new ones will be added to front. */ User->x = x; User->y = y; User->velx = 0; User->vely = 0; User->facdir = 0; User->age = 0; User->frame = 0; User->extra.animate.target = User; /* User->extra.animate.gtype = (genotype*)NULL; The genotype contains the initialization and fertilization data for the player's ship, and different objects in the Player_Dummy list may have different traits, thus the commenting out. */ User->extra.animate.actions = 0; /* presumably all other properties are set-up by whatever process * generates the members of Player_Objects . * * Possible exceptions, shield and energy (always start 'full' ?). */ UN_ObRemove(User); UN_ObInsert(User, &Live_Dummy); UN_HashInsert(User, &Sectors[x >> SUBPOWER][y >> SUBPOWER]); AL_InitPlayerGenome(User); /* my previous comments on this apply. Does a player need a genome * at all? And should it be initialized here, instead of wherever * the object that is to be player is initialized? (what if this is * a probe the player can take over, for instance) */ /* Since the genome includes stuff like initializing the weapons list, * default energy and shields, mass, etc., I'd say that the player needs * a genome. */ AS_GeneratePic(User); } /* Description: * Creates an asteroid. */ void UN_CreateAsteroid() { UN_Object *temp; temp = UN_CreateObject(); temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * ASTEROID_MAX_VELOCITY) - ASTEROID_MAX_VELOCITY; temp->vely = UN_Random(2 * ASTEROID_MAX_VELOCITY) - ASTEROID_MAX_VELOCITY; temp->facdir = UN_Random(256); temp->age = 0; temp->frame = 0; temp->extra.animate.target = temp; temp->extra.animate.gtype = (genotype*)NULL; temp->extra.animate.actions = 0; temp->shield = UN_Random(ASTEROID_MAX_SHIELD); temp->energy = UN_Random(ASTEROID_MAX_ENERGY); temp->mass = UN_Random(ASTEROID_MAX_MASS); UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, &Sectors[temp->x >> SUBPOWER][temp->y >> SUBPOWER]); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER, temp); } AS_GeneratePic(temp); /* Do asteroids have genomes at all? * No. */ } /* ** Creates food (I can't remember what food is like so I'll skip this) . ** ** How long has it been since you've eaten? :) */ void UN_CreateFood() { /* TO BE WRITTEN */ /* We may just want to copy the code from UN_CreateAsteroid(), with slight * modifications to account for this being food. */ } /* Description: * Creates a probe (with genome). */ void UN_CreateProbe(gtype *parents) { UN_Object *temp; temp = UN_CreateObject(); temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * PROBE_MAX_VELOCITY) - PROBE_MAX_VELOCITY; temp->vely = UN_Random(2 * PROBE_MAX_VELOCITY) - PROBE_MAX_VELOCITY; temp->facdir = UN_Random(256); temp->age = 0; temp->frame = 0; temp->extra.animate.target = User; /* (:-> */ temp->extra.animate.gtype = (genotype*)NULL; temp->extra.animate.actions = 0; /* ** presumeably all other properties are set-up by the addition ** of the genome . */ /* the probe genome would contain information on what kind of weapons, * shield size, etc, to invest in most. */ /* AL_InitProbeGenome() would then implement the investment, right? */ UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, &Sectors[temp->x >> SUBPOWER][temp->y >> SUBPOWER]); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER, temp); } AL_InitProbeGenome(temp,parents); /* I'll have to think of the different ways a probe genome can be * initialized/created (random, recombination, from archives) */ AS_GeneratePic(temp); } /* Description: * Returns 1 if the newly created object passed as a parameter overlaps * any other object currently in play; returns 0 otherwise. */ int UN_Collision(UN_Object *which) { /* Need the appropriate parts of movement moving in here. ** Might need two versions of this, one for set up and one for ** play but I think one will crack it. */ /* TO BE WRITTEN */ /* For now, just returns 0, so new objects might appear in the middle of ** old ones. */ return 0; } void UN_KillObject(UN_Object *obj) { /* TO BE WRITTEN */ /* Called when an object is destroyed. Starts a death animation (if desired), * archives it (if desired), and either converts the object to another type of * object (most likely food) or removes the object via UN_DeleteObject(). */ } /* Description: * Moves obj, and determines if it collided into anything */ void UN_Movement(UN_Object *obj) { UN_Object *this_obj; /* might want to make this a global variable instead * for speed */ obj->x += obj->velx; obj->y += obj->vely; /* <> */ subx = obj->x >> SUBPOWER; suby = obj->y >> SUBPOWER; /* did this UN_Object move into a different subsector? */ if ((subx != tempx) || (suby != tempy)) UN_Shift(subx, suby, obj); /* update sector lists */ /* <> */ xh = ((obj->x - SUBSIZE + 1) >> SUBPOWER); yh = ((obj->y - SUBSIZE + 1) >> SUBPOWER); /* This is to get the left and below squares ? , * (subx - 1) & 0xQQQQ might be quicker. */ /* It might be, but then we'd have to re-compute the sector number if * obj->x or obj->y < (SUBSIZE-1) when we checked the object's current * sector. */ for (txh = xh; txh < xh + 2; txh++) { for (tyh = yh; tyh < yh + 2; tyh++) { ttxh = (txh + NUMSUBS) % NUMSUBS; ttyh = (tyh + NUMSUBS) % NUMSUBS; /* Not sure we need the "+ NUMSUBS" 'cos xh & txh are now always +ve */ /* xh and txh can be negative if obj->x < (SUBSIZE-1). */ this_obj = Sectors[ttxh][ttyh]; while (this_obj != NULL) { if ((this_obj == obj) || (this_obj->shield <= 0)) continue; /* Can't collide with yourself, and a bullet's explosion can only hit one * other object per object that the bullet contained. */ if (ttxh == txh) dx = obj->x - this_obj->x; else if (ttxh < txh) dx = obj->x - this_obj->x - (MAX_X); else dx = (MAX_X) + obj->x - this_obj->x; if (dx<0) dx*=(-1); if (ttyh == tyh) dy = obj->y - this_obj->y; else if (ttyh < tyh) dy = obj->y - this_obj->y - (MAX_Y); else dy = (MAX_Y) + obj->y - this_obj->y; if (dy<0) dy*=(-1); /* previous section can probably be made simpler if we also re-do * the following if statement, 'cos only one term of the boolean will * apply to each conditional above. */ if (((dx < this_obj->bboxside) || (dx < obj->bboxside)) && ((dy < this_obj->bboxside) || (dy < obj->bboxside)) && ((dx * dx) + (dy * dy) < (((this_obj->bboxside + obj->bboxside) >> 1) ** 2))) { /* <> !!! */ /* we have a collision between obj and this_obj, so handle it */ if ((this_obj->what == BULLET) || (this_obj->what == MISSILE) || (obj->what == BULLET) || (obj->what == MISSILE)) { if ((obj->what == BULLET) || (obj->what == MISSILE)) { this_obj->shield -= obj->extra.bullet.damage; obj->shield = 0; AS_SetPic(obj->pic, EXPLODE); if (this_obj->shield <= 0) AS_SetPic(this_obj->pic, EXPLODE); } if ((this_obj->what == BULLET) || (this_obj->what == MISSILE)) { obj->shield -= this_obj->extra.bullet.damage; this_obj->shield = 0; AS_SetPic(this_obj->pic, EXPLODE); if (obj->shield <= 0) AS_SetPic(obj->pic, EXPLODE); } } else if ((obj->what <= SUPPLY) && (obj->extra.animate.target == this_obj)) { /* code to handle breeding, grabbing, etc. */ } else if ((this_obj->what <= SUPPLY) && (this_obj->extra.animate.target == obj)) { /* same code with this_obj and obj reversed */ /* not necessary surely 'cos it'll get called in reverse * when this_obj is itself collision detected. */ * After the "generic collision" code below is called on this pass, which * is not necessarily desirable...especially if we implement collision * damage at M4. Plus, if this_obj is going fast enough, it might fly * over obj entirely on its next movement check, which means no collision. * */ } else if ((this_obj->what == STICKY) &&(obj->what == STICKY)) { /* merge two sticky bricks into one object */ } else { /* objects bounce off of each other */ tempx = obj->velx * obj->mass; tempy = obj->vely * obj->mass; /* <> */ obj->velx = (this_obj->velx * this_obj->mass) / obj->mass; obj->vely = (this_obj->vely * this_obj->mass) / obj->mass; this_obj->velx = tempx / this_obj->mass; this_obj->vely = tempy / this_obj->mass; } } this_obj = this_obj->next_hash; } } } } /* <> ** if (obj->velx >= 0) ** obj->x += obj->velx; ** else ** obj->x -= (-1) * (obj->velx); ** ** if (obj->vely >= 0) ** obj->y += obj->vely; ** else ** obj->y -= (-1) * (obj->vely); ** ** I didn't get the previous two if's at all ! ** Isn't "- (-1) * x", identical to "+ x" ? ** remember that unsigned numbers underflow happily as well as overflow. ** (I may be wrong but I'd be suprised) ** ** torrodial space needs no implementation: overflow and underflow should ** take care of this for us */ /* <> ** detect collisions ** ** moved the next comment from inside the loops so I can read it ** ** Need a scorecard yet? What variables are what: (Z=x or y) Zh = the Z coordinate of the topmost/leftmost subsector to check tZh = the Z coorindate of the subsector currently being checked Note that Zh and tZh may be negative or greater than 64, so checks against Sectors[txh][tyh] are not ok. ttZh = tZh normalized to 0 <= ttZh < 64 This allows checks against Sectors[ttxh][ttyh] . dZ = the difference in the Z coordinates of obj and this_obj, as adjusted for torriodal space (we can tell if we need to adjust, and if so, how, by comparing tZh and ttZh. If tZh==ttZh, no adjustment is needed. If tZhttZh, add MAX_Z to obj's Z coordinate before checking. Note: we may want to have one standard bboxside for all objects...this would get rid of four indirect references per collision. If we do this, then the pixel maps would still come in fixed sizes (the largest confined to a circle no more than SUBSIZE in diameter, as is the current plan anyway), but this problem would be avoided. */ /* <> ** There were some bugs in the old detection code: for instance, if ** obj->x == this_obj->x, dx will be 0 (as it should), but the collision ** would be ignored because dx < obj->bboxside (assuming obj->bboxside > 0). ** (The previous check started with ** ((dx < this_obj->bboxside) && (dx > obj->bboxside) && ** (dy < this_boj->bboxside) && (dy > obj->bboxside) && ... ** which also lead to the bug where dx = 4, dy = 0, obj->bboxside = 10, ** and this_obj->bboxside = 2; this is obviously a collision, since obj's ** bounding circle overlaps this_obj's bounding circle, but it would not be ** detected.) ** ** (Badcoe's comment noting another problem snipped, since that problem has ** also been fixed. - ) ** ** The previous is fine as long as all the circles are the ** same size, but if they differ then the centers of the circles are ** offset from their bbox-coords (which are measured to a corner, yes ?) ** by different ammounts. ** ___ ** / \ ** | + | ___ ** \___/ / \ The centers of these are at the same separation as their ** | + | bbox corners. ** \___/ ** ** ___ ** / \ ** | + | _____ ** \___/ / \ The centers of these are at a different separation to their ** | | bbox corners. ** | + | ** | | ** \_____/ ** ** The easiest/fastest solution might be for only a small number of different ** circle sizes (say 8) and an array of relative offsets. */ /* <> **possible collision damage implementation: obj->shield -= ((this_obj->velx * this_obj->velx) + (this_obj->vely * this_obj->vely)) * this_obj->mass; this_obj->shield -= ((obj->velx * obj->velx) + (obj->vely * obj->vely)) * obj->mass; Alternate possibility: Calculate total kinetic energy as above, then recalculate after adjusting momentum, and subtract the difference from each of the colliders' shields (half each? proportional to mass?) */ /*-------------------------------------------------------------------------*/ void UN_ReSeed() { /* TO BE WRITTEN */ /* will have to adjust to make sure that not too many objects are in play at ** once so we don't run out of memory in UN_CreateObject(), and that not too ** few objects are in play at any one time */ } /*-------------------------------------------------------------------------*/ /* : Ideology note :) * I'm still more in favour of the 'contineous model' of the universe. * That is, no new 'levels', but one single play field. * Reason: * - The longer a play field is active, the more interesting things may * evolve in it. Also interesting (plant) pattern formation takes time. * - In this kind of system, it may be too hard to determine things like * 'progressive difficulty' anyway. How to determine which level is * tougher, while the level keeps adapting to the player anyway? Very hard * to say. * We can prevent the 'dying out' of this field by reintroducing * (I suppose this would be reseeding :) 'old heros' into the field. * To have some pauses and changes in play, we can have occasional additions * of new technology/information, accompanied by movies. * * Perhaps a good compromise is a 'scenario' type approach. The player can * choose at the beginning whatever scenario he or she wants to play, and * the scenarios have varying difficulty/properties, dependent on what * we seed them with initially, and all kinds of options set and not set. * * Next to these 'standard scenarios' we can also have the player design * scenarios him/herself, by setting all kinds of options (and there will * be many options possible). * * * My proposal is to ignore level increases and so on for now, and to focus * on getting a single field working (we are doing this anyway..) * * */ char UN_NewSector() { /* Called when a sector has been cleared; this allows the player to choose ** a new sector, then calls UN_InitSector() to create that sector. If the ** player has just cleared the last sector, this returns 1 to end the ** game. */ if (curmovie==7) { /* final sector cleared */ AS_ShowMovie(PLAYER_WON); curmovie=8; return 1; } /* TO BE WRITTEN: code that allows the user to choose which sector to go to */ /* Current implementation: player automatically advances one "wave" each ** sector. */ curmovie++; AS_ShowMovie(curmovie); StartAsteroids=curmovie*50; StartFood=0; StartProbes=curmovie*10; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); return 0; /* game continues */ } /*-------------------------------------------------------------------------*/ void UN_InitGame() { /* calls UN_InitSector() and sets anything else that needs to be set at the ** beginning of the game (for instance, making sure that there is only one ** player life object in the Player_Dummy list) */ UN_Object *temp; while (Live_Dummy.next_ob != &Live_Dummy) UN_DeleteObject(Live_Dummy.next_ob); while (Player_Dummy.next_ob != &Player_Dummy) { temp=Player_Dummy.next_ob; UN_ObRemove(temp); UN_ObInsert(temp, &Spare_Dummy); } UN_ObInsert(UN_CreateObject(),&Player_Dummy); Player_Dummy.next_ob->gtype=NULL; /* player's first ship has no parents */ curmovie=1; AS_ShowMovie(curmovie); StartAsteroids=curmovie*50; StartFood=0; StartProbes=curmovie*10; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); } void UN_DeInitGame() { /* TO BE WRITTEN */ /* Deallocates memory used by dummy objects and their lists */ } /*-------------------------------------------------------------------------*/ char UN_PlayGame() { /* Will be called when a sector has been started, either ** after UN_InitGame() or by a game having been paused in mid ** sector, then unpaused. */ unsigned long ticksleft, nextupdate = FE_Set(); /* how many ticks left until next update, and the time of the next update, ** encoded in a way meaningful to FE and AI */ while (1) { probes_exist = 0; if (User->shield <= 0) { AS_PlayFX(FX_DIE); if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } /* UN_NewLife() returns 1 if no lives left for the player */ for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy;) { tobj = curobj->next_ob; if (curobj->shield <= 0) UN_KillObject(&curobj); /* may remove curobj depending on its status */ curobj = tobj; } for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy; curobj = curobj->next_ob) if (curobj->shield > 0) UN_CheckObject(curobj); if ((ticksleft = FE_GetTicks(nextupdate)) > 0) AI_DoQueue(ticksleft); nextupdate = FE_Update(&Sectors, (User->x) % SUBSIZE,(User->y) % SUBSIZE); /* syskeys that aren't handled below handled here */ if ((SYSKEYS) & KEY_TOGGLE_SOUND) FE_ToggleSound(); if ((SYSKEYS) & KEY_PAUSE) return 2; if ((SYSKEYS) & KEY_QUIT) return MA_ConfirmQuit(2); if (!(probes_exist)) if (UN_NewSector()) return 1; /* We will probably want to change these conditions. */ /* This would be an ideal place to put a possible call ** to UN_ReSeed() if there are too many or too few objects. */ } } /* Return codes for UN_PlayGame: 0 = quitting, 1 = game over, 2 = paused */ From compuserve.com!71044.2164 Mon Nov 20 23:32:41 1995 Return-Path: <71044.2164@compuserve.com> Received: from arl-img-3.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tHnBz-000fKMC; Mon, 20 Nov 95 23:32 PST Received: by arl-img-3.compuserve.com (8.6.10/5.950515) id CAA08485; Tue, 21 Nov 1995 02:25:02 -0500 Date: 21 Nov 95 02:22:32 EST From: Adrian Tymes <71044.2164@compuserve.com> To: AG-Universe Cc: AG-Directors Subject: Universe.h 0.53 Message-ID: <951121072231_71044.2164_GHI35-3@CompuServe.COM> /* Universe header version 0.53, copyright (c) 1995 us * Last modified 11/20/95 by Adrian Tymes */ /* universe.h is now compilable */ /* on (flat mode) 32 bit machines/OSes UN_coord's size is assumed to be * 32 bits. * (in case we ever want to port this to 64 bit machines :) */ typedef unsigned long UN_coord; /* Description: * #defines for UN_Object->what * Comments: * All animate UN_Objects are <= MISSILE * (assuming BULLET exhibits no behaviour, just goes on momentum) */ #define PLAYER 0 #define PROBE 1 #define SUPPLY 2 #define MISSILE 3 #define BULLET 4 #define ASTEROID 5 #define UF_EGG 6 #define F_EGG 7 #define D_EGG 8 #define D_PLAYER 9 #define D_PROBE 10 #define D_SUPPLY 11 #define UNMOVABLE 12 #define SPECIAL 13 #define STICKY 14 /* more #defines */ /* Description: * SUBSIZE: size of a subsector in basic distance units. * SUBPOWER = log(base2) (SUBSIZE) * Intended use: floor(z / SUBSIZE) == z >> SUBPOWER; the second is faster */ #define SUBSIZE 67108864 #define SUBPOWER 26 /* Description: * Two times Pi, for table initialisation.*/ #define TWOPI 6.2831853 /* Description: * Maximum thrust possible for probe * Comments: * WARNING: currently completely arbitrary value, not yet * checked for. Only to give size of ThrustCost[] */ #define MAX_THRUST 100 /* Description: * number of subsectors */ #define NUMSUBS 64 /* Description: * Number of UN_Objects that we allocate at boot-up. * Comments: * Maybe this should be set by the configuration instead? This would * necessitate something (probably FE) being run before UN_InitTable() */ #define STARTOBJECTS 100 /* Description: * Maximum sizes of X, Y values * ( = SUBSIZE * NUMSUBS - 1 ) * This is if unsigned long is 32 bits long */ #define MAX_X (unsigned long) 4294967295 #define MAX_Y (unsigned long) 4294967295 /* Description: * Maximum size of bounding box (equal to subsector) */ #define MAX_BBSIDE SUBSIZE /* Description: /* temporary #define for type action until we decide to use a more advanced ** structure, if we eventually want to...note that we'll have to change the ** keypress #defines in that case */ #define action unsigned long int /* standard UN_Object definition follows */ /* Explanation of structure: typedef struct { unsigned long x, y: location of object long velx, vely: movement vector (needs to be signed) picture *pic: picture for FE and AS unsigned long what: what the object is: PLAYER - player PROBE - probe ASTEROID - asteroid BULLET - bullet (aka: brain-dead missile) MISSILE - missile (aka: homing bullet) UF_EGG - unfertilized egg F_EGG - fertilized egg D_EGG - dead egg D_PLAYER - dead player D_PROBE - dead probe SUPPLY - supply ship D_SUPPLY - dead supply ship UNMOVABLE - unmovable object SPECIAL - special object STICKY - sticky brick; just like asteroid except that two sticky bricks stick together on collision long facdir: facing direction 0...255 (needs to be signed) PLAYER PROBE SUPPLY BULLET MISSILE: for navigation PLAYER PROBE SUPPLY?: for firing every object: for animations, for example after collision objects may perhaps turn - or perhaps not long mass: mass of object (needs to be signed for momentum computations) NOTE: mass should *never* be less than or equal to zero!! (and mass shouldn't be too low either) PLAYER PROBE SUPPLY BULLET MISSILE: thrust needs this every object: collision needs this unsigned long bboxside: length of side of bounding box every object: collision needs this long shield: currently remaining shield of object (needs to be signed) every object: if shield <= zero then the object dies What happens upon death: PLAYER -> D_PLAYER PROBE -> D_PROBE ASTEROID -> breaks into smaller asteroids or vanishes BULLET -> explodes, then vanishes MISSILE -> explodes, then vanishes UF_EGG -> D_EGG F_EGG -> D_EGG D_EGG -> vanishes D_PLAYER -> vanishes D_PROBE -> vanishes SUPPLY -> D_SUPPLY D_SUPPLY -> vanishes UNMOVABLE -> vanishes (or may be indestructable?) SPECIAL -> depends on what we do with this STICKY -> breaks into smaller sticky bricks or vanishes long energy: currently remaining energy of object (needs to be signed) can be used for navigation/firing by animate objects, and is used to denote nutricious value for inanimate objects PLAYER PROBE MISSILE SUPPLY: used for thrust PLAYER PROBE SUPPLY(?): for firing weapons PLAYER PROBE: to lay an egg, and to fertilize an egg UF_EGG: energy may decay slowly; also nutricious value F_EGG: energy is invested in properties; also nutricious value D_PLAYER D_PROBE D_SUPPLY D_EGG ASTEROID STICKY UNMOVABLE: nutricious value unsigned long age: Frames since creation or last "what" change - probes may use age to base actions on - eggs can hatch at a certain time after fertilisation - certain weapons may explode after a certain time - nutricious value (energy) of dead objects may degenerate with age - statistical purposes unsigned char frame: current frame of animation for AS (0 to 255, cycling) Now for the shared memory with extra non generic object information: union { struct { UN_Object *target: current target of object long thrust: thrust power of object long turn: turn speed of object genotype *gtype: pointer to genotype of object - alife stuff UN_Object *wlist: pointer to the current weapon in the weapon list of this object - system needs to be refined later, but a copy of whatever this points to will be created if the object fires; the list object's x variable is its energy cost to fire (maybe we should also have a shield cost for certain weapons, as the y variable?) action actions: virtual keypresses done by this probe } animate; (used by PLAYER, PROBE, and SUPPLY) struct { long damage: explosive force of object long type: type of explosion (only contact-damage is supported right now) } bullet; (used by BULLET only) That is, MISSILE should have thrust and turn, just like a normal probe. It should have a type of explosion as well. So a seperate missile struct in the shared memory may be necessary. (perhaps another struct for 'special' stuff, like food and eggs) } extra; UN_Object *next_hash: pointer to next object in list UN_Object **prev_hash: pointer to pointer at this object, **(ob->prev_hash)=ob if (ob!=first object on its sector list) *(ob->prev_hash)= previous_ob->next_hash else *(ob->prev_hash)= sector[ob->x >> SUBSIZE][ob->y >> SUBSIZE] If you're confused by this, UN_Shift() should clear up the way object->prev_hash, object->next_hash, objects, and Sectors[][] are used. Note that this is only for objects in the objects list. There may be other objects that are on completely seperate lists (weapon lists, for instance?) UN_Object *next_ob, *prev_ob: Used for objects and spares linked lists in a similar manner as next_hash and prev_hash; see UN_DeleteObject() for details on this and spares. Expanded {next,prev}_ob to be a fully linked list 'cos it's useful for target switching {and not used v.often so speed less important than for {next,prev}_hash} } UN_Object; */ /* Condensed: */ /* I messed around with this structure for a long time before I could * get it to compile properly. * * One trick was adding 'struct' keywords in front of the UN_Object fields * in this struct. Things would compile, however with warnings of improper * type assignments, as now some functions assign 'UN_Object' to * 'struct UN_Object'. * * Another way to get it to compile was to rename the entire struct into * something like Temp_Object, and then place * 'typedef struct Temp_Object UN_Object' in front of it all. * But, this came up with bugs, the compiler complained it didn't know the * size of the thing anymore. * * Finally I solved it all with a cheap hack; the define following * makes everything compilable.. * It isn't very beautiful, and if anybody knows a better way, * I'm all ears. */ /* WARNING: very cheap hack, but works */ #define UN_Object struct UN_Object UN_Object { UN_coord x, y; long velx, vely; picture *pic; long facdir, shield, energy, mass; unsigned long what, bboxside, age; unsigned char frame; union { struct { UN_Object *target; long thrust,turn; genotype *gtype; UN_Object *wlist; action actions; } animate; struct { long damage, type; } bullet; } extra; UN_Object *next_hash, **prev_hash; UN_Object *next_ob, *prev_ob; }; /* Description: * Live_Objects points to the start of the linked list containing * all UN_Objects in play. * Spare_Objects points to allocated UN_Objects not currently being * used. (these are reusable) * Sectors contains the subsector lists of objects. * Player_Objects points to the start of the linked list with all * objects owned by the player (? not sure if this was the intention ) * (more precisely, it holds the player's extra lives, which are not in play * when they're in the Player_Objects list ) */ UN_Object *Live_Objects, *Spare_Objects, *Player_Objects; UN_Object *Sectors[NUMSUBS][NUMSUBS]; UN_Object *User; /* pointer to current player's probe */ char curwhat; /* current what the object is */ long probes_exist; /* (how many) probes still exist */ long curthrust; /* current thrust */ long tempx, tempy; /* temporary subsector holders */ long subx, suby; /* more temporary subsector holders */ float UN_sin[256], UN_cos[256]; /* precomputed sin and cos lookup tables */ UN_Object *curobj; /* pointer to UN_Object currently being checked */ UN_Object *tobj; /* a temporary UN_Object pointer holder */ long curpic; /* current picture number for UN_Object */ long xh,txh,ttxh,dx,yh,tyh,ttyh,dy; /* variables for collision detection */ long StartAsteroids,StartFood,StartProbes; /* how many objects of each type to create at the beginning of the game */ UN_Object Dummies[NUMSUBS][NUMSUBS]; UN_Object Live_Dummy; UN_Object Spare_Dummy; UN_Object Player_Dummy; /* dummy objects - do not alter these outside the UN_ routines */ /* current picture number = * frame (0-255) + THRUSTPIC + BRAKEPIC + TARGETPIC */ #define THRUSTPIC 256 #define BRAKEPIC 512 #define TARGETPIC 1024 /* ** I'm sure we can't afford 1024 pictures per UN_Object (type) ? ** ** And we won't: 256 pictures (maximum) for each type, with the appropriate ** "thrusting" picture overlaid if (picture number)&256, similar for braking ** and targetting. In addition, similar types of objects would share their ** pictures (for instance, all of one type of asteroid, all of one species of ** probe, etc.). And if we can't afford 256 pictures per object type, then ** use the same picture for multiple frames: if we only want 64 pictures per ** object type, frames 0, 64, 128, and 192 would share the same picture, as ** would frames 1, 65, 129, and 193, et cetera. Also, note that braking and ** thrusting will never be displayed at the same time, since the universe code ** won't allow an object to thrust and brake simultaneously. */ #define SYSKEYS User->extra.animate.actions /* User always points to the current player's ship, and system keys will * always be passed to the universe (as opposed to main/menu) part of the game * by that object's actions */ /* group shared defines added here */ /* screens used in FE_DisplayScreen(screen)) */ #define MAINMENU 0 #define PAUSEMENU 1 #define CONFIRMQUITDIALOG 2 /* keypresses returned by AI_GetKeys() and FE_GetKeys() */ #define KEY_QUIT 0x80000000 #define KEY_PAUSE 0x40000000 #define KEY_TOGGLE_SOUND 0x20000000 /* KEY_x = system key, not avaiable to non-player objects */ /* I've made KEY_x scale from the high end and other keys scale from the low ** end to allow a lot of flexibility in how many system keys vs. how many ** "regular" keys we want to have. */ #define THRUST 0x00000001 #define BRAKE 0x00000002 #define LEFT 0x00000004 #define RIGHT 0x00000008 #define NEXTTARGET 0x00000010 #define LASTTARGET 0x00000020 #define FIRE 0x00000040 /* more #defines needed: movies used in AS_ShowMovie(movie): OUTRO CREDITS INSTRUCTIONS INTRO (should be 0) GAME_OVER The above should be #defined by AS, which should also allow movies input by curmovie (1 through 7, "starting level x", may be a longer range). other #defines needed: STARTOBJECTS (defined in universe.h, but maybe this should be set by FE?) AI define: MAX_THRUST AI define: THRUST_FAIL AI define: BRAKE_FAIL AI define: FIRE_FAIL FE define: TARGET_RADIUS (number of universe points away that another object can be targetted at...defines a square area with side TARGET_RADIUS*2) (FE since this should be probably be dependent on the player's view size) ASTEROID_MAX_SHIELD ASTEROID_MAX_ENERGY ASTEROID_MAX_MASS ASTEROID_MAX_VELOCITY PROBE_MAX_VELOCITY AS define: EXPLODE (for AS_SetPic()) AS define: FX_DIE (for AS_PlayFX()) */ /* function prototypes */ /* prototypes of other groups' functions that UN uses (commented out since ** these are also supposed to be in their headers: void FE_DisplayScreen(long screen); void FE_DisplayError(long errornum); short FE_InitSystem(); void FE_PointerStatus(short *x,short *y,char *b1,char *b2); void FE_DeInitSystem(); action FE_GetKeys(); action AI_GetKeys(UN_Object *obj); void AI_Interrupt(UN_Object *obj, long type); * need #define for THRUST_FAIL and BRAKE_FAIL types * And also various other possible interrupts, like COLLISION, etc, * or HEAVY_ENERGY_LOSS, or whatever else is easy to notice in universe * void AS_SetPic(picture *pic,long type); * handles animation * long ThrustCost[MAX_THRUST]; * lookup for thrustcost * long FE_Set(); void AS_PlayFX(long type); void AS_ShowMovie(long number); long FE_GetTicks(long NextUpdate); void AI_DoQueue(long FE_TicksLeft); int FE_Update(UN_Object *(*Subsectors[NUMSUBS][NUMSUBS]), int CenterSubSectorX, int CenterSubSectorY) * removed passing of Sectors (FE should probably know this * anyway), besides I'm tired and can't get it to pass the right * pointer, somehow. :) * restored passing of Sectors * void FE_ToggleSound(); short MA_ConfirmQuit(short mode); void AL_InitPlayerGenome(UN_Object *player); void AL_InitProbeGenome(UN_Object *thing,gtype *parents); void AS_GeneratePic(UN_Object *obj); ** And now for the UN prototypes: */ unsigned long UN_Random(unsigned long max); void UN_CheckObject(UN_Object *obj); void UN_Shift(long sectx, long secty, UN_Object *obj); void UN_InsertObject(long sectx, long secty, UN_Object *obj); UN_Object *UN_CreateObject(); void UN_DeleteObject(UN_Object *obj); void UN_InitTable(); void UN_ReSeed(); void UN_InitSector(); char UN_NewSector(); void UN_InitGame(); short UN_NewLife(); char UN_PlayGame(); void UN_DeInitGame(); void UN_ObInsert(UN_Object *ob, UN_Object *dummy); void UN_ObRemove(UN_Object *ob); void UN_HashInsert(UN_Object *ob, UN_Object **list); void UN_HashRemove(UN_Object *ob); void UN_Animate(UN_Object *obj); void UN_Movement(UN_Object *obj); void UN_CreatePlayer(UN_coord x, UN_coord y); void UN_CreateAsteroid(); void UN_CreateFood(); void UN_CreateProbe(gtype *parents); int UN_Collision(UN_Object *which); void UN_KillObject(UN_Object *obj); void UN_DeInitGame(); From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:03:41 1995 Return-Path: Received: from hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmAE-000fJ8C; Wed, 29 Nov 95 05:03 PST Received: from hpqs0123.sqf.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA026979696; Wed, 29 Nov 1995 04:54:58 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA165869695; Wed, 29 Nov 1995 12:54:55 GMT From: Stuart McDonald Message-Id: <199511291254.AA165869695@hpqs0123.sqf.hp.com> Subject: v0.6 Universe.h To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 12:54:55 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] #ifndef UNIVERSE_H_ #define UNIVERSE_H_ /* Universe header version 0.60, copyright (c) 1995 us * Last modified 11/23/95 by Stuart McDonald */ /* Description: * Values for UN_Object->what * Comments: * All animate UN_Objects are <= MISSILE * (assuming BULLET exhibits no behaviour, just goes on momentum) * PLAYER - player * PROBE - probe * ASTEROID - asteroid * BULLET - bullet (aka: brain-dead missile) * MISSILE - missile (aka: homing bullet) * UF_EGG - unfertilized egg * F_EGG - fertilized egg * D_EGG - dead egg * D_PLAYER - dead player * D_PROBE - dead probe * SUPPLY - supply ship * D_SUPPLY - dead supply ship * UNMOVABLE - unmovable object * SPECIAL - special object * STICKY - sticky brick; just like asteroid except that two sticky * bricks stick together on collision */ /* SMD: Changed to enum coz easier to add new animate types */ typedef unsigned char UN_ObjType; enum { PLAYER=0, PROBE, SUPPLY, MISSILE, BULLET, ASTEROID, UF_EGG, F_EGG, D_EGG, D_PLAYER, D_PROBE, D_SUPPLY, UNMOVABLE, SPECIAL, STICKY, L_OTYPE }; /* Description: * Number of UN_Objects that we allocate at boot-up. * Comments: * Maybe this should be set by the configuration instead? This would * necessitate something (probably FE) being run before UN_InitTable() */ #define STARTOBJECTS 100 /* Description: * SUBSIZE: size of a subsector in basic distance units. (= 1<> SUBPOWER; the second is faster */ #define SUBPOWER 26 #define SUBSIZE 0x4000000 /* Description: * Number of subsectors. This = (1 << (32-SUBPOWER)) */ #define NUMSUBS 64 /* Description: * Maximum sizes of X, Y values * ( = SUBSIZE * NUMSUBS - 1 ) * This is if unsigned long (a UN_coord) is 32 bits long */ /* SMD: Added cast */ #define MAX_X ((UN_coord) 4294967295) #define MAX_Y ((UN_coord) 4294967295) /* Description: * Maximum size of bounding box (equal to subsector) */ #define MAX_BBSIDE SUBSIZE /* Description: * Coordinate in the universe */ typedef unsigned long UN_coord; /* Description: * NUM_DIRS is the number of an directions an object can face in. * Comment: SMD: Why does it need to be signed? 'facdir' is a direction and * it is used to access UN_sin/cos and we wrap it at 256 (now NUM_DIRS) */ #define NUM_DIRS 256 typedef signed long UN_Direction; /* Description: * Velocity of an object */ /* SMD: typedef'ed */ typedef signed long UN_Velocity; /* Description: * Temporary typedef for type UN_Action until we decide to use a more advanced * structure, if we eventually want to...note that we'll have to change the * keypress #defines in that case */ /* SMD: Typedef'ed */ typedef unsigned long int UN_Action; /* Description: * Current animation frame of object. If object has less that 256 frames then * frame numbers share same picture. e.g. with 64 frame per object then * same 1, 64, 128 and 192 would be the same. * Note: Turn in Animate assumes 8 bit size for Frame, also THRUSTPIC * must be larger than UN_Frame size /* SMD: typedef'ed */ typedef unsigned char UN_Frame; /* Description: * Bit flags which are OR'ed with the current frame of an object to produce * a picture number. If bit is set then when frame is drawn the appropriate * thrust/brake/target picture is overlaid ontop. E.g. if the picture number * is 514 then it is frame 2 with Braking */ #define THRUSTPIC 0x100 #define BRAKEPIC 0x200 #define TARGETPIC 0x400 #define EXPLODEPIC 0x800 /***************************** * 'Extra' Info structs ****************************/ /* SMD: Typdef'ed the 'extra' structs since we will no doubt be adding more of these. */ struct UN_Object_s; /* * UN_AnimateInfo: (used by PLAYER, PROBE, SUPPLY, and MISSILE) * * UN_Object *target - current target of object * long thrust - thrust power of object * UN_Angle turn - turn speed of object * AI_Genome *gtype - pointer to genome of object - alife stuff * UN_Object *wlist - pointer to the current weapon in the weapon * list of this object. System needs to be refined * later, but a copy of whatever this points to will be * created if the object fires; the list object's x * variable is its energy cost to fire (maybe we should also * have a shield cost for certain weapons, as the y variable?) * UN_Action actions - virtual keypresses done by this probe */ typedef struct UN_AnimateInfo_s { struct UN_Object_s *target; UN_Direction turn; signed short thrust; struct AI_Genome_s *gtype; struct UN_Object_s *wlist; UN_Action actions; } UN_AnimateInfo; /* * UN_BulletInfo: (used by BULLET only) * long damage - explosive force of object * long type - type of explosion (only contact-damage is * supported right now) */ typedef struct UN_BulletInfo_s { long damage; long type; } UN_BulletInfo; /* * That is, MISSILE should have thrust and turn, just like * a normal probe. It should have a type of explosion as well. So * a seperate missile struct in the shared memory may be necessary. * (perhaps another struct for 'special' stuff, like food and eggs) * SMD: How about * * typedef struct UN_MissileInfo_s { * AnimateInfo animate * long type; * } UN_MissileInfo; * * union { * UN_AnimateInfo animate; * UN_MissileInfo missile; * UN_BulletInfo bullet; * } extra; * * * Then when just the 'animate' part needs to be accessed i.e. in UN_Animate * it can be accessed as object->extra.animate and the 'type' can be accessed * as object->extra.missile.type. It's maybe kind of 'hackish' though 8-) */ /***************************** * Object Struct ****************************/ /* * UN_Object: * * UN_coord x, y - location of object * UN_Velocity velx, vely - movement vector (needs to be signed) * AS_Picture *pic - picture info for FE and AS * UN_ObjType what - what the object is * UN_Direction facdir - facing direction 0...255 (needs to be signed) * PLAYER * PROBE * SUPPLY * BULLET * MISSILE : for navigation * PLAYER * PROBE * SUPPLY? : for firing * Every obj : for animations, for example after collision * objects may perhaps turn - or perhaps not * long mass - mass of object (needs to be signed for * momentum computations) * NOTE: mass should *never* be less than or equal to zero!! * (and mass shouldn't be too low either) * Every obj : collision needs this * unsigned long bboxside - length of side of bounding box * Every obj : collision needs this * long shield - remaining shield of object (needs to be signed) * Every object: if shield <= zero then the object dies * What happens upon death: * PLAYER -> D_PLAYER * PROBE -> D_PROBE * ASTEROID -> breaks into smaller asteroids or vanishes * BULLET -> explodes, then vanishes * MISSILE -> explodes, then vanishes * UF_EGG -> D_EGG * F_EGG -> D_EGG * D_EGG -> vanishes * D_PLAYER -> vanishes * D_PROBE -> vanishes * SUPPLY -> D_SUPPLY * D_SUPPLY -> vanishes * UNMOVABLE -> vanishes (or may be indestructable?) * SPECIAL -> depends on what we do with this * STICKY -> breaks into smaller sticky bricks or vanishes * long energy - remaining energy of object (needs to be signed) * can be used for navigation/firing by animate objects, and is * used to denote nutricious value for inanimate objects * PLAYER * PROBE * MISSILE * SUPPLY : used for thrust * PLAYER * PROBE * SUPPLY(?) : for firing weapons * PLAYER * PROBE : to lay an egg, and to fertilize an egg * UF_EGG : energy may decay slowly; also nutricious value * F_EGG : energy invested in properties; also nutricious value * D_PLAYER * D_PROBE * D_SUPPLY * D_EGG * ASTEROID * STICKY * UNMOVABLE : nutricious value * unsigned long age - Frames since creation or last "what" change * probes may use age to base UN_Actions on * eggs can hatch at a certain time after fertilisation * certain weapons may explode after a certain time * nutricious value (energy) of dead objects may degenerate with age * statistical purposes * UN_Frame frame - frame of animation for AS (0 to 255, cycling) * ******* * * Now for the shared memory with extra non generic object information. These * are accessed via object->extra.animate etc. * * UN_AnimateInfo animate - Animation info * UN_BulletInfo bullet - Bullet info * ******* * * Now for the list information * * * UN_Object *next_hash - pointer to next object in list * UN_Object **prev_hash - pointer to pointer at this object, * * **(ob->prev_hash)=ob * if (ob!=first object on its sector list) * *(ob->prev_hash)= previous_ob->next_hash * else * *(ob->prev_hash)= sector[ob->x >> SUBSIZE][ob->y >> SUBSIZE] * * If you're confused by this, UN_Shift() should clear up the way * object->prev_hash, object->next_hash, objects, and Sectors[][] are * used. * * Note that this is only for objects in the objects list. There may * be other objects that are on completely seperate lists (weapon lists, * for instance?) * * UN_Object *next_ob, * *prev_ob - Used for objects and spares linked lists in a * similar manner as next_hash and prev_hash; see UN_DeleteObject() * for details on this and spares. * * Expanded {next,prev}_ob to be a fully linked list 'cos it's * useful for target switching {and not used v.often so speed less * important than for {next,prev}_hash} */ struct AS_Picture_s; typedef struct UN_Object_s { UN_coord x, y; UN_Velocity velx, vely; struct AS_Picture_s *pic; UN_Direction facdir; long shield, energy; unsigned short mass; UN_ObjType what; unsigned short bboxside; unsigned short age; UN_Frame frame; union { UN_AnimateInfo animate; UN_BulletInfo bullet; } extra; struct UN_Object_s *next_hash, **prev_hash; struct UN_Object_s *next_ob, *prev_ob; } UN_Object; /***************************** * Global Data ****************************/ /* SMD: Does anyone else need access to any of these? */ /* Description: * Sectors contains the subsector lists of objects.*/ extern UN_Object *Sectors[NUMSUBS][NUMSUBS]; /* Description: * Live_Objects points to the start of the linked list containing * all UN_Objects in play. * Spare_Objects points to allocated UN_Objects not currently being * used. (these are reusable) * Player_Objects points to the player's extra lives, which are not * in play when they're in the Player_Objects list */ extern UN_Object *Live_Objects, *Spare_Objects, *Player_Objects; /* Description: * Pointer to current player's probe */ extern UN_Object *User; /* Description: * User always points to the current player's ship, and system keys will * always be passed to the universe (as opposed to main/menu) part of the game * by that object's actions */ #define SYSKEYS User->extra.animate.actions /* group shared defines added here */ /* Description: * Bit masks for keypresses returned by AI_GetKeys() and FE_GetKeys() */ #define KEY_QUIT 0x80000000 #define KEY_PAUSE 0x40000000 #define KEY_TOGGLE_SOUND 0x20000000 /* KEY_x = system key, not avaiable to non-player objects */ /* I've made KEY_x scale from the high end and other keys scale from the low * end to allow a lot of flexibility in how many system keys vs. how many * "regular" keys we want to have. */ #define THRUST 0x00000001 #define BRAKE 0x00000002 #define LEFT 0x00000004 #define RIGHT 0x00000008 #define NEXTTARGET 0x00000010 #define LASTTARGET 0x00000020 #define FIRE 0x00000040 /* Description: */ #define ASTEROID_MAX_SHIELD 1 #define ASTEROID_MAX_ENERGY 1 #define ASTEROID_MAX_MASS 1 #define ASTEROID_MAX_VELOCITY 1 #define PROBE_MAX_VELOCITY 1 /* Description: * Values passed into AI_Interrupt, typedef anyone? */ /* Also need various other possible interrupts, like COLLISION, etc, * or HEAVY_ENERGY_LOSS, or whatever else is easy to notice in universe */ enum { THRUST_FAIL=1, BRAKE_FAIL, FIRE_FAIL }; /***************************** * Function Prototypes ****************************/ /* Description: * Generate a random number between 0..max-1 */ /* SMD: Is this meant to return 0..max-1 or 0..max ? * Also, maybe add a 16 bit Random for speed or write our own. Anyone? */ unsigned long UN_Random(unsigned long max); /* Description: * The once only setup routine. e.g. create sin and cos tables. */ void UN_InitTable(); /* Description: * Setup anything needed before starting a new game */ void UN_InitGame(); /* Description: * Play the game in all its glory (either after pause or new game). * Returns: * 0 = Definately quitting (not used at the moment) * 1 = Game Over * 2 = Paused * 3 = Want to Quit (but prompt first) */ char UN_PlayGame(); /* Description: * Shutdown the UN_ stuff, e.g. free memory etc. */ void UN_DeInitGame(); #endif From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:04:20 1995 Return-Path: Received: from relay.hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmBL-000fJJC; Wed, 29 Nov 95 05:04 PST Received: from hpqs0123.sqf.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA162299765; Wed, 29 Nov 1995 04:56:06 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA165989759; Wed, 29 Nov 1995 12:56:00 GMT From: Stuart McDonald Message-Id: <199511291256.AA165989759@hpqs0123.sqf.hp.com> Subject: v0.6 Universe.c To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 12:55:59 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] /***************************************************************************\ * Alife Game - universe.c code file * * ------------------------------------------------------------------------- * * Copyright (C) 1995 Us. All Rights Reserved. * * ------------------------------------------------------------------------- * * Last Revised: 11/23/95 * * By: Stuart McDonald * * Version #: 0.60 * \***************************************************************************/ #include /* for sin and cos */ #include /* for definition of NULL */ #include "main.h" #include "universe.h" #include "fe.h" #include "as.h" #include "alife.h" #define SQR(a) ((a)*(a)) #define ABS(a) ((a) < 0 ? (0-(a)) : (a)) /***************************** * Global Variables ****************************/ UN_Object *Live_Objects, *Spare_Objects, *Player_Objects; UN_Object *Sectors[NUMSUBS][NUMSUBS]; UN_Object *User; /***************************** * Function Prototypes (local) ****************************/ /* SMD: I assume no one outside of UN_ will call these? */ static void UN_CheckObject(UN_Object *obj); static void UN_Animate(UN_Object *obj); static void UN_Movement(UN_Object *obj); static int UN_Collision(UN_Object *which); static UN_Object *UN_CreateObject(); static void UN_InsertObject(long sectx, long secty, UN_Object *obj); static void UN_DeleteObject(UN_Object *obj); static void UN_KillObject(UN_Object *obj); static void UN_ObInsert(UN_Object *ob, UN_Object *dummy); static void UN_ObRemove(UN_Object *ob); static void UN_HashInsert(UN_Object *ob, UN_Object **list); static void UN_HashRemove(UN_Object *ob); static short UN_NewLife(); static char UN_NewSector(); static void UN_InitSector(); static void UN_ReSeed(); static void UN_Shift(long sectx, long secty, UN_Object * obj); static void UN_CreatePlayer(UN_coord x, UN_coord y); static void UN_CreateAsteroid(); static void UN_CreateFood(); static void UN_CreateProbe(AI_Genome *parents); /***************************** * Filescope Variables ****************************/ /* dummy objects */ static UN_Object Dummies[NUMSUBS][NUMSUBS]; static UN_Object Live_Dummy; static UN_Object Spare_Dummy; static UN_Object Player_Dummy; /* how many objects of each type to create at the beginning of the game */ static long StartAsteroids, StartFood, StartProbes; /* (how many) probes still exist */ static long probes_exist; /* Precomputed sin and cos lookup tables */ static float UN_sin[NUM_DIRS], UN_cos[NUM_DIRS]; /* */ static long ThrustCost[MAX_THRUST]; /* * Renamed (more meaningful and also Capitalized for important arrays): * objects -> Live_Objects * spares -> Spare_Objects * sector -> Sectors * thrustcost ->ThrustCost * * *_Objects are all gone now (Sic Transit Gloria Mundi) instead we * now do all list access *through* the dummy object, e.g. * Live_Dummy.next_ob is the first live object. * We could have MACRO's defined for these but do we really need * them ? */ /***************************** * Function Definitions ****************************/ /* * Inserts an UN_Object into the specified object list (which * means Live_Objects, Spare_Objects or Player_Objects at the moment). * * Now that this is doubly linked and we have dummies, we no longer need * pointers to the lists and can access them through the dummies * themselves . * * Assumes that the UN_Object was correctly removed from any * previous list it belonged to. */ /* Description: * Inserts UN_Object ob as next object of UN_Object dummy, * in a doubly linked list. * Comments: * Assumes that the UN_Object was correctly removed from any * previous list it belonged to. (like the Spare_Objects list) */ static void UN_ObInsert(UN_Object *ob, UN_Object *dummy) { ob->prev_ob = dummy; ob->next_ob = dummy->next_ob; dummy->next_ob->prev_ob = ob; dummy->next_ob = ob; } /* Description: * Removes UN_Object from doubly linked list it belongs to. * Comments: * WARNING: UN_Object has to be in a doubly linked list! */ static void UN_ObRemove(UN_Object *ob) { (ob->next_ob)->prev_ob = ob->prev_ob; (ob->prev_ob)->next_ob = ob->next_ob; } /* * Next two routines are exactly like previous two but act on sector * lists. */ /* Description: * Inserts an object into a subsector list. * Comments: * Assumes that this object was correctly removed from its previous * subsector list */ static void UN_HashInsert(UN_Object *ob, UN_Object **list) { ob->prev_hash = list; ob->next_hash = *list; (*list)->prev_hash = &(ob->next_hash); *list = ob; } /* Description: * Removes object from its subsector list. * Comments: * Object has to be in subsector list! */ static void UN_HashRemove(UN_Object *ob) { (ob->next_hash)->prev_hash = ob->prev_hash; *(ob->prev_hash) = ob->next_hash; } /* Description: * Move an UN_Object from one sector list to another. */ static void UN_Shift(long sectx, long secty, UN_Object * obj) { /* first remove us from our old list */ UN_HashRemove(obj); /* now insert us at the start of the new list */ UN_HashInsert(obj, &(Sectors[sectx][secty])); } /* initialize starting UN_Objects (as in, we *know* that we'll need at least * STARTOBJECTS UN_Objects, so let's allocate them while the user expects * initialization lag) */ /* * I'm assuming that this gets called exactly once. * * That's the current plan. */ /* Description: * Initializes starting UN_Objects. * Comments: * We know we'll need at least STARTOBJECTS Un_Objects anyway, so * let's allocate them while the user expects initialization lag. * Assumed is that this function gets called exactly once. */ void UN_InitTable() { /* SMD: Moved this here since only place needed */ /* Two times Pi, for table initialisation.*/ #define TWOPI 6.2831853 int i; UN_Object *tobj; /* a temporary UN_Object pointer holder */ Live_Dummy.prev_ob = &Live_Dummy; /* make a closed doubly-linked list */ Live_Dummy.next_ob = &Live_Dummy; /* with one member */ Spare_Dummy.prev_ob = &Spare_Dummy; /* ditto */ Spare_Dummy.next_ob = &Spare_Dummy; Player_Dummy.prev_ob = &Player_Dummy; /* ditto */ Player_Dummy.next_ob = &Player_Dummy; Live_Objects = &Live_Dummy; Spare_Objects = &Spare_Dummy; Player_Objects = &Player_Dummy; /* I didn't see these initialized or defined elsewhere... */ /* * The following leaves undefined UN_Objects in the Spare_Objects list, * UN_InitSector will initialise and move them to Live_Objects * as things are created. */ tobj = (UN_Object *)FE_malloc(sizeof(UN_Object) * STARTOBJECTS); /* SMD: Changed i=1 to i=0 */ for (i = 0; i < STARTOBJECTS; i++) { /* Removed & in front of Spare_Objects, is already a pointer */ UN_ObInsert(tobj++, Spare_Objects); } /* Now to initialize UN_sin[] and UN_cos[] lookup tables */ for (i = 0; i < NUM_DIRS; i++) { UN_sin[i] = (float) sin((double)i * (double)TWOPI / (double)NUM_DIRS); UN_cos[i] = (float) cos((double)i * (double)TWOPI / (double)NUM_DIRS); /* GNU C (which is probably one of the compilers we will be working with) * expects radians, so I changed it to that. (Since radians are ANSI also) * Also I sprinkled plenty of typecasts all over the thing, to make sure * it doesn't do that wrong. */ /* SMD: i < 255 meant last entry was not getting initialised. */ } } /* used to insert a new UN_Object into the * objects list and its Sectors[][] list; assumes that nothing critical is * being pointed to only by obj->prev_hash, obj->next_hash, obj->next_ob, or * obj->prev_ob * * Note: I've updated this function but the things it does don't * make a lot of sense 'cos the UN_Objects list and sectors lists * aren't likely to be adjusted at the same time now * we have Spare_Objects. */ /* Description: * Inserts a UN_Object into the objects list and its Sectors[][] list * at the same time. * Comments: * As we are working with Spare_Objects now, this function is probably * obsolete. * Assumes nothing critical is being pointed to by obj->prev_hash, * obj->next_hash, obj->next_ob, and obj->prev_ob. */ static void UN_InsertObject(long sectx, long secty, UN_Object *obj) { /* Removed & in front of Live_Objects */ UN_ObInsert(obj, Live_Objects); UN_HashInsert(obj, &(Sectors[sectx][secty])); } /* Description: * - Returns a (new) UN_Object (from the Spare_Objects list, or newly * allocated if none available. * * Comments: * - Don't assume anything about initial conditions of any value in the * UN_Object (including next_ob and prev_ob)! So EVERY value has to be * initialized. * - Doesn't yet include check if there is sufficient memory left! */ static UN_Object *UN_CreateObject() { UN_Object *tob; /* formerly this declaration was inside the function, * which isn't possible in ANSI C */ /* SMD: Moved it back, it is ANSIC C */ /* There was a bug here, != should be ==, so I corrected this * (if I understand this correctly!) */ if (Spare_Dummy.next_ob == &Spare_Dummy) { /* if there is no spare object left, allocate new object */ return (UN_Object *)FE_malloc(sizeof(UN_Object)); /* WARNING: Include free memory check! */ } else { /* there are still spare objects, so return one */ tob = Spare_Dummy.next_ob; UN_ObRemove(tob); return tob; } } /* Description: * Removes an object in the Live_Objects list from that list, and also * removes it from its Sectors[][] list. * It will then be inserted into the Spare_Objects list, so later the * memory can be reused by a new object. */ static void UN_DeleteObject(UN_Object *obj) { UN_ObRemove(obj); UN_HashRemove(obj); UN_ObInsert(obj, &Spare_Dummy); } /* Description: * UN_CheckObject is called for each object each 'tick' */ /* SMD: Hmmm, after reading the above I have no idea how the 'ticks' works * (and I thought I did) */ static void UN_CheckObject(UN_Object *obj) { static UN_ObjType curwhat; static long curpic; /* current picture number for UN_Object */ curwhat = obj->what; /* type of UN_Object is stored in curwhat */ if ((curwhat == BULLET) || (curwhat == MISSILE)) { /* these types have a maximum lifespan set at creation */ (obj->age)--; if (obj->age == 0) (obj->shield) = 0; } else (obj->age)++; /* get keys & virtual keys */ switch (curwhat) { case PLAYER: /* this is the player */ obj->extra.animate.actions = FE_GetKeys(); /* get the real keypresses */ break; /* <<1>> */ case PROBE: /* this is a probe */ probes_exist++; /* count surviving probes */ case MISSILE: /* probe remote control, and standard control routines */ /* get the virtual keypresses from a short AI routine - * real alife work is done elsewhere */ obj->extra.animate.actions = AI_GetKeys(obj); break; /* case SUPPLY */ } /* end of switch(curwhat) */ /* Animate the object and calculate it's current picture */ curpic = 0; if (curwhat <= MISSILE) { /* this is an animate UN_Object */ UN_Animate(obj); if (obj->extra.animate.actions & THRUST) curpic = THRUSTPIC; else if (obj->extra.animate.actions & BRAKE) curpic = BRAKEPIC; } if (User->extra.animate.target == obj) { curpic |= TARGETPIC; } /* Note that curpic is set in the code that was move to UN_Animate(); * it might be clearer to move all curpic setting code in that function * (which for now consists of detecting thrusting and braking) back into * this function. */ /* SMD: Is the above reasonable? */ UN_Movement(obj); /* Movement update */ AS_SetPic(obj->pic, curpic | obj->frame); /* <<2>> */ obj->frame++; /* frame, being an unsigned char, should ignore overflow */ } /* ** <<1>> this makes all objects of type PLAYER act in exactly the same ** way...we might want to have some other means of controlling PLAYER ** objects that aren't currently being controlled by the player. */ /* * My assumption was that if we have objects 'owned' by the player but * currently not controlled by the player, then they will have an extra * variable set somewhere 'owned by the player'. (or will be in a special * 'owned by player list') Therefore, their 'what' variable will not * be PLAYER. It is assumed only one such object is around at the * time. (until we create a multiplayer networked version :) * * The PLAYER objects in play all correspond to things using the player's * keypresses for control. The player's bullets, missiles, etc. are of * 'what' BULLET, MISSILE, etc., while the player's objects that are not * currently in play are in the Player_Dummy list. Unless and until we * have more than one player ship in the game at a time, what other objects * does the player own? */ /* ** <<2>> Sets the current picture so FE can just display it if it is visible, ** also allows cycling of colors. ** ** Since AS does not care about facing, I replaced facdir's bits with current ** frame bits. Not many platforms at the moment can support 256 frames of ** animation per sprite, but the capability's there if any platform we port ** to ever does want it. For less frames, the current frame is this number ** mod however many frames desired, which will still cycle through one frame ** of animation per update. Effect overlays (TARGETPIC, etc.) still must be ** accounted for. */ /* Description: * Updates animate objects (turning, thrusting). */ static void UN_Animate(UN_Object *obj) { static long curthrust; /* Thrust of object being animated */ static UN_ObjType curwhat; curwhat = obj->what; if (obj->extra.animate.actions & THRUST) { /* forward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx += (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely += (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ } else { /* not enough energy for thrust */ /* FE call here for thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_Interrupt(obj, THRUST_FAIL); /* <> */ } } /* end of not enough energy code */ } /* end of THRUST code */ else if (obj->extra.animate.actions & BRAKE) { /* backward thrust */ curthrust = obj->extra.animate.thrust; if (obj->energy - ThrustCost[curthrust] >= 0) { /* if enough energy */ /* <> */ obj->velx -= (curthrust / obj->mass) * UN_sin[obj->facdir]; obj->vely -= (curthrust / obj->mass) * UN_cos[obj->facdir]; /* energy cost of this brake thrust */ obj->energy -= ThrustCost[curthrust]; /* lookup for thrustcost */ } else { /* not enough energy for brake thrust */ /* FE call here for brake thrust fail art/sound, currently none */ if (curwhat == PROBE) { AI_Interrupt(obj, BRAKE_FAIL); /* "hardware" interrupt */ } } /* end of not enough energy code */ } /* end of BRAKE code - end of THRUST/BRAKE code */ /* * NOTE: we might want to kick out different turn speeds, and use a * standard turnspeed instead for each object */ if (obj->extra.animate.actions & LEFT) { /* turn to the left */ /* <> */ #if 0 /* Faster, but assumes 2's compliment */ obj->facdir = (obj->facdir - obj->extra.animate.turn) & NUM_DIRS-1; #endif obj->facdir = (obj->facdir > obj->extra.animate.turn) ? (obj->facdir - obj->extra.animate.turn) & NUM_DIRS-1 : NUM_DIRS - (obj->extra.animate.turn - obj->facdir); /* <> */ } /* end of LEFT code */ else if (obj->extra.animate.actions & RIGHT) { /* turn to the right */ /* turning to the right, so clockwise, means increasing angle */ obj->facdir = (obj->facdir + obj->extra.animate.turn) & NUM_DIRS-1; } /* end of RIGHT code */ if (curwhat == PLAYER) { if (obj->extra.animate.actions & NEXTTARGET) { /* cycle to next target */ do { do { obj->extra.animate.target = obj->extra.animate.target->next_ob; } while ((ABS(obj->extra.animate.target->x - obj->x) > TARGET_RADIUS) || (ABS(obj->extra.animate.target->y - obj->y) > TARGET_RADIUS)); } while (obj->extra.animate.target != &Live_Dummy); } else if (obj->extra.animate.actions & LASTTARGET) { /* cycle to previous target */ do { do { obj->extra.animate.target = obj->extra.animate.target->prev_ob; } while ((ABS(obj->extra.animate.target->x - obj->x) > TARGET_RADIUS) || (ABS(obj->extra.animate.target->y - obj->y) > TARGET_RADIUS)); } while (obj->extra.animate.target != &Live_Dummy); } } /* Partially fixed targetting code, but it needs to be able to handle * wraparound */ if (obj->extra.animate.actions & FIRE) { /* Added primitive fire code */ if (obj->energy >= obj->extra.animate.wlist->x) { /* if enough energy; cost = prototype's x variable */ UN_Object *temp; temp = UN_CreateObject(); temp->x = obj->x + obj->velx + obj->velx; temp->y = obj->y + obj->vely + obj->vely; /* Two adds are at least as fast as an add and a multiply: x + (2*velx) */ temp->velx = obj->velx; temp->vely = obj->vely; /* We will eventually have to implement fast and slow bullets. */ temp->facdir = obj->facdir; temp->extra.bullet.type = obj->extra.animate.wlist->extra.bullet.type; temp->extra.bullet.damage = obj->extra.animate.wlist->extra.bullet.damage; temp->what = obj->extra.animate.wlist->what; temp->shield = obj->extra.animate.wlist->shield; temp->energy = obj->extra.animate.wlist->energy; temp->mass = obj->extra.animate.wlist->mass; temp->age = obj->extra.animate.wlist->age; temp->bboxside = obj->extra.animate.wlist->bboxside; UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, &Sectors[temp->x >> SUBPOWER][temp->y >> SUBPOWER]); /* SMD: Removed '&' from temp */ /* SMD: Should this not be GeneratePic? */ AS_InitializePic(temp); obj->energy -= obj->extra.animate.wlist->x; } else { /* not enough energy to fire */ /* FE call here for fire fail art/sound, currently none */ if (curwhat == PROBE) { AI_Interrupt(obj, FIRE_FAIL); /* "hardware" interrupt */ } } /* end of not enough energy code */ } /* end of FIRE code */ /* need to add in cycle weapon code for PLAYER/PROBE */ /* one possibility: have objects outside of the objects list be the * prototypes for each weapon, with next_hash/prev_hash forming a circular * double-linked list for each object; cycle weapon would then get the next (or * previous) object on that list, while fire would merely make a duplicate of * that weapon into the objects list, editing velocity, position, and (if * needed) target as needed */ /* need to add in eat code for PLAYER/PROBE */ /* need to add in energy to shield code for PLAYER/PROBE/SUPPLY */ /* need to add in breed stuff */ /* need to add in pick up/drop */ /* these last two could merely set flags (for instance, * object->extra.animate.actions & BREED) that could be * checked if the object bumps into another object, since * fertilization and grabbing will only be processed when an * object that is trying to do that comes into contact with * another one */ /* Another possibility for breed/grab/eat is to use the targetting code, * and enable breeding/grabbing/eat at a limited distance, so the probes won't * have to do complicated maneuvering just to grab something..*/ } /* ** <> assuming navigation system with north = 0, clockwise increase ** calculate vector changes */ /* ** <> hardware interrupt for AI, note that hardware interrupt calls ** don't do anything directly; the interrupt is just registered, ** later the interrupt handler will handle it */ /* <> turning to left, so counterclockwise, means decreasing angle ** ** % operator doesn't work here, because when turning left the facdir ** will never rise above 255. Instead code is needed to handle facdir ** < 0. This code will break with turnspeed > 256 :) ** ** I've changed it to use "&" which should work on all 2's compliment ** systems (which I *think* is ANSI for C). ** ** Although it is widely used, 2's compliment is apparently not ANSI C. ** There is a good chance that all of the systems we write this for will ** be 2's compliment, however, so maybe we should check with FE before ** changing this just in case we don't have to. */ /* In general, I suggest we make a list of all the non-ANSI assumptions * we've made. (like size of long, under/overflow, and 2's compliment) * */ /* SMD: Changed it to a (slightly) slower version that doesnt assume * 2's compliment. */ /* ** <> code and comments removed ** if (obj->facdir < 0) { ** obj->facdir += 256; ** } ** ** alternatively (if faster?) use: obj->facdir = (256 + (obj->facdir - ** obj->extra.animate.turn)) % 256 */ /* Description: * Called when the player's probe has just died. This routine determines * if the player has any 'lives' left. If so, it turns one of the player's * 'life' objects into the player object, sets whatever variables that are * needed for it to be the player, then returns 0. If the player is * out of lives, it returns 1, which the main play lookps takes as a signal * to end the game. * Comments: * No parametres should be needed, since the object and subsector lists * are global. */ static short UN_NewLife() { /* this depends on how we implement 'lives'. An idea I've been toying with * is to let all lives be either eggs, or even active probes. When the player * dies the player owned eggs/probes are checked, and one is picked to * reincarnate the player. * Also, a nice animation would be required (egg hatching, whatever) * in this case. */ if (Player_Dummy.prev_ob == &(Player_Dummy)) return 1; else { UN_CreatePlayer(User->x,User->y); /* default initial placement */ return 0; } } /* * Does the player have to be 'object #0' 'genotype #0'? Do we indeed still * have numbered objects at all? * * As of now, we are not using numbered objects. */ /* Description: * Initializes a sector (including "dummy" objects at the end of subsector * lists), populates it with food sources, asteroids, and probes, then * places the player somewhere in the sector. */ static void UN_InitSector() { int i, j; UN_Object *tobj; /* a temporary UN_Object pointer holder */ /* Tidy Object lists by just dumping any Live_Objects onto * Spare_Objects. (This leaves inactive Player_Objects untouched.) */ while((tobj = Live_Dummy.next_ob) != &Live_Dummy) { UN_ObRemove(tobj); UN_ObInsert(tobj, &Spare_Dummy); } /* This could be done as a single transfer but I'm too tired */ /* Just blank the hash tables. */ for(i = 0; i < NUMSUBS; i++) { for(j = 0; j < NUMSUBS; j++) { Sectors[i][j] = &(Dummies[i][j]); Dummies[i][j].prev_hash = &(Sectors[i][j]); Dummies[i][j].next_hash = Sectors[i][j]; /* next_hash shouldn't ever be referenced but this may be safer */ } } UN_CreatePlayer(0,0); /* As good a place as any to start :) */ for(i = 0; i < StartAsteroids; i++) { UN_CreateAsteroid(); } for(i = 0; i < StartFood; i++) { UN_CreateFood(); } for(i = 0; i < StartProbes; i++) { UN_CreateProbe(NULL); /* This isn't the only place a genome could come from. This is where 'seed' ** genomes arise (from the archive of previous heroes ? (In which case the ** archiving routines might eventually fall into a different function heading ** AR_* ?)). */ /* True, however, UN_CreateProbe() will always need to have a genome for ** the created probe, so I've moved the genome creation call to inside the ** UN_CreateProbe() routine. */ /* But genome creation depends on universe circumstances. That is, if * two probes cooperate to lay an egg, the genome creaton code needs to * do something entirely different than when a random probe is thrown * into the universe, or a nonrandom probe is retrieved from the archives. * */ /* I've changed a call to include a parameter for AI so it can tell how the * probe was created, NULL being the code for "random/no parent". */ } /* ** ... ** Insert any other object type you want to start with here. */ } /* Description: * Pulls a player object off the waiting stack (Player_Dummy) and sets it up * as the active player. If there aren't any on the stack, behaviour * is undefined (might ultimately create a default one but I don't yet * know enough to say what 'default' is). * Comments: * Default: this procedure should not be called if * Player_Dummy.prev_ob == &(Player_Dummy). * This implies something like UN_CreatePlayerLife. */ static void UN_CreatePlayer(UN_coord x, UN_coord y) { User = Player_Dummy.prev_ob; /* Use last craft from list (e.g. FIFO) * as new ones will be added to front. */ /* SMD: Added setting of what */ User->what = PLAYER; User->x = x; User->y = y; User->velx = 0; User->vely = 0; User->facdir = 0; User->age = 0; User->frame = 0; User->extra.animate.target = User; #if 0 User->extra.animate.gtype = (AI_Genome*)NULL; The genotype contains the initialization and fertilization data for the player's ship, and different objects in the Player_Dummy list may have different traits, thus the commenting out. #endif User->extra.animate.actions = 0; /* presumably all other properties are set-up by whatever process * generates the members of Player_Objects . * * Possible exceptions, shield and energy (always start 'full' ?). */ /* SMD: Just setting some values so other code will work ok */ User->mass = 100; User->shield = 100; User->energy = 100; UN_ObRemove(User); UN_ObInsert(User, &Live_Dummy); UN_HashInsert(User, &Sectors[x >> SUBPOWER][y >> SUBPOWER]); AL_InitPlayerGenome(User); /* my previous comments on this apply. Does a player need a genome * at all? And should it be initialized here, instead of wherever * the object that is to be player is initialized? (what if this is * a probe the player can take over, for instance) */ /* Since the genome includes stuff like initializing the weapons list, * default energy and shields, mass, etc., I'd say that the player needs * a genome. */ AS_GeneratePic(User); } /* Description: * Creates an asteroid. */ static void UN_CreateAsteroid() { UN_Object *temp; temp = UN_CreateObject(); /* SMD: Added setting of what */ temp->what = ASTEROID; temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * ASTEROID_MAX_VELOCITY) - ASTEROID_MAX_VELOCITY; temp->vely = UN_Random(2 * ASTEROID_MAX_VELOCITY) - ASTEROID_MAX_VELOCITY; temp->facdir = UN_Random(NUM_DIRS); temp->age = 0; temp->frame = 0; temp->extra.animate.target = temp; temp->extra.animate.gtype = (AI_Genome*)NULL; temp->extra.animate.actions = 0; /* SMD: Added +1's (assuming rand returns 0..max-1 */ temp->shield = UN_Random(ASTEROID_MAX_SHIELD)+1; temp->energy = UN_Random(ASTEROID_MAX_ENERGY)+1; temp->mass = UN_Random(ASTEROID_MAX_MASS)+1; UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, &Sectors[temp->x >> SUBPOWER][temp->y >> SUBPOWER]); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER, temp); } AS_GeneratePic(temp); /* Do asteroids have genomes at all? * No. */ } /* * Creates food (I can't remember what food is like so I'll skip this) . * * How long has it been since you've eaten? :) */ static void UN_CreateFood() { /* TO BE WRITTEN */ /* We may just want to copy the code from UN_CreateAsteroid(), with slight * modifications to account for this being food. */ /* SMD: What is food? Since we dont have an UN_ObjType defined for it. Also may want to look at re-using some of the common stuff rather than cut and pasting for each type */ } /* Description: * Creates a probe (with genome). */ static void UN_CreateProbe(AI_Genome *parents) { UN_Object *temp; temp = UN_CreateObject(); /* SMD: Added setting of what */ temp->what = PROBE; temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); temp->velx = UN_Random(2 * PROBE_MAX_VELOCITY) - PROBE_MAX_VELOCITY; temp->vely = UN_Random(2 * PROBE_MAX_VELOCITY) - PROBE_MAX_VELOCITY; temp->facdir = UN_Random(NUM_DIRS); temp->age = 0; temp->frame = 0; temp->extra.animate.target = User; /* (:-> */ temp->extra.animate.gtype = (AI_Genome*)NULL; temp->extra.animate.actions = 0; /* * presumeably all other properties are set-up by the addition * of the genome . */ /* SMD: Justing setting some values so other code will work ok */ temp->mass = 100; temp->shield = 100; temp->energy = 100; /* the probe genome would contain information on what kind of weapons, * shield size, etc, to invest in most. */ /* AL_InitProbeGenome() would then implement the investment, right? */ UN_ObInsert(temp, &Live_Dummy); UN_HashInsert(temp, &Sectors[temp->x >> SUBPOWER][temp->y >> SUBPOWER]); while(UN_Collision(temp)) { temp->x = UN_Random(MAX_X); temp->y = UN_Random(MAX_Y); UN_Shift(temp->x >> SUBPOWER, temp->y >> SUBPOWER, temp); } AL_InitProbeGenome(temp, parents); /* I'll have to think of the different ways a probe genome can be * initialized/created (random, recombination, from archives) */ AS_GeneratePic(temp); } /* Description: * Returns 1 if the newly created object passed as a parameter overlaps * any other object currently in play; returns 0 otherwise. */ /* TO BE WRITTEN */ static int UN_Collision(UN_Object *which) { /* Need the appropriate parts of movement moving in here. * Might need two versions of this, one for set up and one for * play but I think one will crack it. */ /* For now, just returns 0, so new objects might appear in the middle of * old ones. */ if (which == NULL) return 1; return 0; } /* Description: */ static void UN_KillObject(UN_Object *obj) { static UN_ObjType deathWhat[L_OTYPE] = { D_PLAYER, /* Player */ D_PROBE, /* Probe */ ASTEROID, /* Asteroid */ L_OTYPE, /* Bullet */ L_OTYPE, D_EGG, D_EGG, L_OTYPE, L_OTYPE, L_OTYPE, D_SUPPLY, L_OTYPE, L_OTYPE, SPECIAL, STICKY }; /* TO BE WRITTEN */ /* Called when an object is destroyed. Starts a death animation (if desired), * archives it (if desired), and either converts the object to another type of * object (most likely food) or removes the object via UN_DeleteObject(). */ if ((obj->what = deathWhat[obj->what]) == L_OTYPE) UN_DeleteObject(obj); } /* Description: * Moves obj, and determines if it collided into anything */ static void UN_Movement(UN_Object *obj) { static long xh,txh,ttxh,dx; /* vars for collision detection */ static long yh,tyh,ttyh,dy; static UN_coord tempx, tempy; /* temporary subsector holders */ static UN_coord subx, suby; static UN_Object *this_obj; /* store original subsector */ tempx = obj->x >> SUBPOWER; tempy = obj->y >> SUBPOWER; /* corrected to use bit shift */ obj->x += obj->velx; obj->y += obj->vely; /* <> */ subx = obj->x >> SUBPOWER; suby = obj->y >> SUBPOWER; /* did this UN_Object move into a different subsector? */ if ((subx != tempx) || (suby != tempy)) UN_Shift(subx, suby, obj); /* update sector lists */ /* <> */ xh = ((obj->x - SUBSIZE + 1) >> SUBPOWER); yh = ((obj->y - SUBSIZE + 1) >> SUBPOWER); /* This is to get the left and below squares ? , * (subx - 1) & 0xQQQQ might be quicker. */ /* It might be, but then we'd have to re-compute the sector number if * obj->x or obj->y < (SUBSIZE-1) when we checked the object's current * sector. */ for (txh = xh; txh < xh + 2; txh++) { for (tyh = yh; tyh < yh + 2; tyh++) { ttxh = (txh + NUMSUBS) % NUMSUBS; ttyh = (tyh + NUMSUBS) % NUMSUBS; /* Not sure we need the "+ NUMSUBS" 'cos xh & txh are now always +ve */ /* xh and txh can be negative if obj->x < (SUBSIZE-1). */ /* SMD: xh = 63 (ie NUMSUBS-1) if obj->x < (SUBSIZE-1) */ this_obj = Sectors[ttxh][ttyh]; /* SMD: Sectors lists are no longer null terminated. Changed this_obj != NULL to this_obj != this_obj->next_hash since the Dummy objects point back at themselves. Yes? */ while (this_obj != this_obj->next_hash) { /* Can't collide with yourself, and a bullet's explosion can only hit one * other object per object that the bullet contained. */ /* SMD: Added moving on to next object to stop inf loop */ if ((this_obj == obj) || (this_obj->shield <= 0)) { this_obj = this_obj->next_hash; continue; } if (ttxh == txh) dx = obj->x - this_obj->x; else if (ttxh < txh) dx = obj->x - this_obj->x - (MAX_X); else dx = (MAX_X) + obj->x - this_obj->x; if (dx<0) dx*=(-1); if (ttyh == tyh) dy = obj->y - this_obj->y; else if (ttyh < tyh) dy = obj->y - this_obj->y - (MAX_Y); else dy = (MAX_Y) + obj->y - this_obj->y; if (dy<0) dy*=(-1); /* previous section can probably be made simpler if we also re-do * the following if statement, 'cos only one term of the boolean will * apply to each conditional above. */ if ( (dx < this_obj->bboxside || dx < obj->bboxside) && (dy < this_obj->bboxside || dy < obj->bboxside) && (dx * dx + dy * dy < SQR((this_obj->bboxside + obj->bboxside) >> 1)) ) { /* <> !!! */ /* we have a collision between obj and this_obj, so handle it */ if ( (this_obj->what == BULLET) || (this_obj->what == MISSILE) || (obj->what == BULLET) || (obj->what == MISSILE) ) { if ( (obj->what == BULLET) || (obj->what == MISSILE) ) { this_obj->shield -= obj->extra.bullet.damage; obj->shield = 0; AS_SetPic(obj->pic, EXPLODEPIC); if (this_obj->shield <= 0) AS_SetPic(this_obj->pic, EXPLODEPIC); } if ( (this_obj->what == BULLET) || (this_obj->what == MISSILE) ) { obj->shield -= this_obj->extra.bullet.damage; this_obj->shield = 0; AS_SetPic(this_obj->pic, EXPLODEPIC); if (obj->shield <= 0) AS_SetPic(obj->pic, EXPLODEPIC); } } else if ( (obj->what <= SUPPLY) && (obj->extra.animate.target == this_obj) ) { /* code to handle breeding, grabbing, etc. */ } else if ( (this_obj->what <= SUPPLY) && (this_obj->extra.animate.target == obj)) { /* same code with this_obj and obj reversed */ /* not necessary surely 'cos it'll get called in reverse * when this_obj is itself collision detected. * After the "generic collision" code below is called on this pass, which * is not necessarily desirable...especially if we implement collision * damage at M4. Plus, if this_obj is going fast enough, it might fly * over obj entirely on its next movement check, which means no collision. * */ } else if ( (this_obj->what == STICKY) && (obj->what == STICKY)) { /* merge two sticky bricks into one object */ } else { /* objects bounce off of each other */ tempx = obj->velx * obj->mass; tempy = obj->vely * obj->mass; /* <> */ obj->velx = (this_obj->velx * this_obj->mass) / obj->mass; obj->vely = (this_obj->vely * this_obj->mass) / obj->mass; this_obj->velx = tempx / this_obj->mass; this_obj->vely = tempy / this_obj->mass; } } this_obj = this_obj->next_hash; } } } } /* <> ** if (obj->velx >= 0) ** obj->x += obj->velx; ** else ** obj->x -= (-1) * (obj->velx); ** ** if (obj->vely >= 0) ** obj->y += obj->vely; ** else ** obj->y -= (-1) * (obj->vely); ** ** I didn't get the previous two if's at all ! ** Isn't "- (-1) * x", identical to "+ x" ? ** remember that unsigned numbers underflow happily as well as overflow. ** (I may be wrong but I'd be suprised) ** ** torrodial space needs no implementation: overflow and underflow should ** take care of this for us */ /* <> ** detect collisions ** ** moved the next comment from inside the loops so I can read it ** ** Need a scorecard yet? What variables are what: (Z=x or y) Zh = the Z coordinate of the topmost/leftmost subsector to check tZh = the Z coorindate of the subsector currently being checked Note that Zh and tZh may be negative or greater than 64, so checks against Sectors[txh][tyh] are not ok. ttZh = tZh normalized to 0 <= ttZh < 64 This allows checks against Sectors[ttxh][ttyh] . dZ = the difference in the Z coordinates of obj and this_obj, as adjusted for torriodal space (we can tell if we need to adjust, and if so, how, by comparing tZh and ttZh. If tZh==ttZh, no adjustment is needed. If tZhttZh, add MAX_Z to obj's Z coordinate before checking. Note: we may want to have one standard bboxside for all objects...this would get rid of four indirect references per collision. If we do this, then the pixel maps would still come in fixed sizes (the largest confined to a circle no more than SUBSIZE in diameter, as is the current plan anyway), but this problem would be avoided. */ /* <> ** There were some bugs in the old detection code: for instance, if ** obj->x == this_obj->x, dx will be 0 (as it should), but the collision ** would be ignored because dx < obj->bboxside (assuming obj->bboxside > 0). ** (The previous check started with ** ((dx < this_obj->bboxside) && (dx > obj->bboxside) && ** (dy < this_boj->bboxside) && (dy > obj->bboxside) && ... ** which also lead to the bug where dx = 4, dy = 0, obj->bboxside = 10, ** and this_obj->bboxside = 2; this is obviously a collision, since obj's ** bounding circle overlaps this_obj's bounding circle, but it would not be ** detected.) ** ** (Badcoe's comment noting another problem snipped, since that problem has ** also been fixed. - ) ** ** The previous is fine as long as all the circles are the ** same size, but if they differ then the centers of the circles are ** offset from their bbox-coords (which are measured to a corner, yes ?) ** by different ammounts. ** ___ ** / \ ** | + | ___ ** \___/ / \ The centers of these are at the same separation as their ** | + | bbox corners. ** \___/ ** ** ___ ** / \ ** | + | _____ ** \___/ / \ The centers of these are at a different separation to their ** | | bbox corners. ** | + | ** | | ** \_____/ ** ** The easiest/fastest solution might be for only a small number of different ** circle sizes (say 8) and an array of relative offsets. */ /* <> **possible collision damage implementation: obj->shield -= ((this_obj->velx * this_obj->velx) + (this_obj->vely * this_obj->vely)) * this_obj->mass; this_obj->shield -= ((obj->velx * obj->velx) + (obj->vely * obj->vely)) * obj->mass; Alternate possibility: Calculate total kinetic energy as above, then recalculate after adjusting momentum, and subtract the difference from each of the colliders' shields (half each? proportional to mass?) */ /*-------------------------------------------------------------------------*/ /* Description: * Generate a random number between 0..max-1 * Comments * For a random coord wont ever generate MAX_X/Y (no big deal). */ unsigned long UN_Random(unsigned long max) { return (((unsigned long)rand()) * ((unsigned long) rand()) % max); } /*-------------------------------------------------------------------------*/ /* Description: */ static void UN_ReSeed() { /* TO BE WRITTEN */ /* will have to adjust to make sure that not too many objects are in play at ** once so we don't run out of memory in UN_CreateObject(), and that not too ** few objects are in play at any one time */ } /*-------------------------------------------------------------------------*/ /* : Ideology note :) * I'm still more in favour of the 'contineous model' of the universe. * That is, no new 'levels', but one single play field. * Reason: * - The longer a play field is active, the more interesting things may * evolve in it. Also interesting (plant) pattern formation takes time. * - In this kind of system, it may be too hard to determine things like * 'progressive difficulty' anyway. How to determine which level is * tougher, while the level keeps adapting to the player anyway? Very hard * to say. * We can prevent the 'dying out' of this field by reintroducing * (I suppose this would be reseeding :) 'old heros' into the field. * To have some pauses and changes in play, we can have occasional additions * of new technology/information, accompanied by movies. * * Perhaps a good compromise is a 'scenario' type approach. The player can * choose at the beginning whatever scenario he or she wants to play, and * the scenarios have varying difficulty/properties, dependent on what * we seed them with initially, and all kinds of options set and not set. * * Next to these 'standard scenarios' we can also have the player design * scenarios him/herself, by setting all kinds of options (and there will * be many options possible). * * * My proposal is to ignore level increases and so on for now, and to focus * on getting a single field working (we are doing this anyway..) * * */ /* Description: */ static char UN_NewSector() { /* Called when a sector has been cleared; this allows the player to choose ** a new sector, then calls UN_InitSector() to create that sector. If the ** player has just cleared the last sector, this returns 1 to end the ** game. */ if (curmovie==7) { /* final sector cleared */ AS_ShowMovie(PLAYER_WON); curmovie=8; return 1; } /* TO BE WRITTEN: code that allows the user to choose which sector to go to */ /* Current implementation: player automatically advances one "wave" each ** sector. */ curmovie++; AS_ShowMovie(curmovie); StartAsteroids=0; /* Note: StartFood must be 0 coz the CreateFood code aint written */ StartFood=0; StartProbes=2; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); return 0; /* game continues */ } /*-------------------------------------------------------------------------*/ /* Description: */ void UN_InitGame() { /* calls UN_InitSector() and sets anything else that needs to be set at the ** beginning of the game (for instance, making sure that there is only one ** player life object in the Player_Dummy list) */ UN_Object *temp; while (Live_Dummy.next_ob != &Live_Dummy) UN_DeleteObject(Live_Dummy.next_ob); while (Player_Dummy.next_ob != &Player_Dummy) { temp=Player_Dummy.next_ob; UN_ObRemove(temp); UN_ObInsert(temp, &Spare_Dummy); } UN_ObInsert(UN_CreateObject(),&Player_Dummy); /* player's 1st ship has no parents */ Player_Dummy.next_ob->extra.animate.gtype=(AI_Genome*)NULL; curmovie=1; AS_ShowMovie(curmovie); StartAsteroids=0; /* Note: StartFood must be 0 coz the CreateFood code aint written */ StartFood=0; StartProbes=2; /* Arbitrary starting constants - someone *please* revise them. */ UN_InitSector(); } /* Description: */ void UN_DeInitGame() { /* TO BE WRITTEN */ /* Deallocates memory used by dummy objects and their lists */ } /*-------------------------------------------------------------------------*/ /* Description: * Called when a sector has been started, either after UN_InitGame() * or by a game having been paused in mid sector, then unpaused. * Returns: * 0 = definately quitting (no used at the momemnt, but there anyway) * 1 = game over, 2 = paused, 3 = want to quit (but prompt to be sure) */ char UN_PlayGame() { UN_Object *curobj; UN_Object *tobj; /* a temp UN_Object pointer holder */ FE_Ticks ticksleft; /* Ticks left until next update */ FE_Ticks nextupdate; /* Time of next update */ nextupdate = FE_Set(); while (1) { probes_exist = 0; /* Check if player dead */ if (User->shield <= 0) { AS_PlayFX(FX_DIE); /* UN_NewLife() returns 1 if no lives left for the player */ if (UN_NewLife()) { AS_ShowMovie(GAME_OVER); return 1; } } /* Check if any other objects dead */ for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy;) { tobj = curobj->next_ob; if (curobj->shield <= 0) /* may remove curobj depending on its status */ /* SMD: Removed '&' from curobj */ UN_KillObject(curobj); curobj = tobj; } /* Process all objects in the universe e.g. move, animate etc. */ for (curobj = Live_Dummy.next_ob; curobj != &Live_Dummy; curobj = curobj->next_ob) if (curobj->shield > 0) UN_CheckObject(curobj); /* Give time to AI to 'do thar thang' */ if ((ticksleft = FE_GetTicks(nextupdate)) > 0) AI_DoQueue(ticksleft); /* Do the front end e.g. draw the screen etc. */ /* SMD: Removed '&' from Sectors and changed '%' to '/' */ nextupdate = FE_Update(Sectors, (User->x) / SUBSIZE,(User->y) / SUBSIZE); /* Check the the system keys */ if ((SYSKEYS) & KEY_TOGGLE_SOUND) FE_ToggleSound(); if ((SYSKEYS) & KEY_PAUSE) return 2; /* SMD: Seemed unnecessary for UN_ to call a MA_ function when it * was going to return to the MA_ code anyway. */ if ((SYSKEYS) & KEY_QUIT) return 3; /* Check for no probes left */ /* We will probably want to change these conditions. * This would be an ideal place to put a possible call * to UN_ReSeed() if there are too many or too few objects. */ if (!(probes_exist)) if (UN_NewSector()) return 1; } } From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:05:24 1995 Return-Path: Received: from relay.hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmCL-000fJLC; Wed, 29 Nov 95 05:05 PST Received: from hpqs0123.sqf.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA163089829; Wed, 29 Nov 1995 04:57:11 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA166099829; Wed, 29 Nov 1995 12:57:09 GMT From: Stuart McDonald Message-Id: <199511291257.AA166099829@hpqs0123.sqf.hp.com> Subject: v0.6 main.h To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 12:57:08 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] #ifndef MAIN_H_ #define MAIN_H_ /* Description: * A universe-and-main internal variable with the current movie (0 when * not in a game, otherwise equal to the current level, or GAME_WON * (= last level + 1) if the player's just won the game). */ /* Movie numbers would be more generic if we didn't make any assumptions * about a level structure. To make the game really extensible we could even * come up with a movie linked list instead. */ extern short curmovie; /* Description: * Struct to hold a button since FE will probably need these to draw the * MAINMENU etc */ /* SMD: typedef it to a FE_ScreenPos anyone? */ typedef struct MA_Button_s { unsigned long ulx,uly,lrx,lry; } MA_Button; /* Description: * Declarations of all the buttons. Used by FE_DisplayScreen to draw them */ extern MA_Button NEW_btn, REP_btn, LOAD_btn, CONT_btn, INST_btn, SAVE_btn, OPT_btn, CRED_btn, QUIT_btn, YES_btn, NO_btn; #endif From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:06:07 1995 Return-Path: Received: from relay.hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmD5-000fJRC; Wed, 29 Nov 95 05:06 PST Received: from hpqs0123.sqf.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA163519874; Wed, 29 Nov 1995 04:57:56 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA166209874; Wed, 29 Nov 1995 12:57:54 GMT From: Stuart McDonald Message-Id: <199511291257.AA166209874@hpqs0123.sqf.hp.com> Subject: v0.6 main.c To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 12:57:53 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] /***************************************************************************\ * Alife Game - main.c code file * * ------------------------------------------------------------------------- * * Copyright (C) 1995 Us. All Rights Reserved. * * ------------------------------------------------------------------------- * * Created by: Adrian Tymes * * Last Revised: 11/26/95 * * By: Stuart McDonald * * Version #: 0.60 * \***************************************************************************/ #include "main.h" #include "universe.h" #include "alife.h" #include "fe.h" #include "as.h" /* Description: * #define to create button boundaries. * b = button name * ulx, uly = upper left corner x and y coordinates * xw, yh = width and height of button * All on points 0-1023, 0-767 screen */ #define BUTTON(b, ulx,uly,xw,yh) \ MA_Button b##_btn = { ulx, uly, ulx+xw, uly+yh } /* Buttons: * NEW - New Game * LOAD - Load Game * SAVE - Save Game NOTE: Disabled unless game paused * CONT - Continue Game NOTE: Disabled unless game paused * REP - Replay Movie NOTE: "Show Background Story" when game paused * INST - Instructions * OPT - Options * CRED - Credits * QUIT - Quit * YES - Yes NOTE: Same boundaries as OPT * NO - Yes NOTE: Same boundaries as QUIT * * Layout: * * NEW REP LOAD * * CONT INST SAVE * * OPT CRED QUIT * */ /* NOTE: If add button here also need to externally declare it in main.h */ BUTTON(NEW, 200, 150, 207, 155); BUTTON(CONT, 200, 306, 207, 155); BUTTON(OPT, 200, 462, 207, 155); BUTTON(REP, 408, 150, 207, 155); BUTTON(INST, 408, 306, 207, 155); BUTTON(CRED, 408, 462, 207, 155); BUTTON(LOAD, 616, 150, 207, 155); BUTTON(SAVE, 616, 306, 207, 155); BUTTON(QUIT, 616, 462, 207, 155); BUTTON(YES, 200, 462, 207, 155); BUTTON(NO, 616, 462, 207, 155); /* Description: * Returns TRUE only if coordinates x, y are within boundaries a,b,c,d */ #define MA_Within(x,y,a,b,c,d) ((x>a)&&(xb)&&(y Many options will be possible, especially for universe and alife. * This will therefore require careful thought. */ static void MA_Options() { /* TO BE WRITTEN */ } /* Description: * This function presents a dialog that prompts the user to confirm that * the user wants to quit the game. If the user confirms, this function * returns 0, otherwise it returns the input parameter. * Comments: * FE_PointerStatus is assumed to update the pointer's screen * representation. */ static short MA_ConfirmQuit(short mode) { char b1, b2; short x, y; FE_DisplayScreen(CONFIRMQUITDIALOG); while (1) { b1 = 0; while (!b1) { /* This also updates the pointer's screen representation, right? */ FE_PointerStatus(&x, &y, &b1, &b2); } if (MA_CheckButton(YES, x, y)) return 0; else if (MA_CheckButton(NO, x, y)) return mode; } } /* Description: * - Initializes tables * - Initializes front end (displays error if unable to) * - Initializes sound (but this may be done in front end already) * - Shows intro movie * - Handles main menu */ int main(int argc, char *argv[]) { FE_ErrorNum err; short go; short x, y; char b1, b2; /* Initialize tables */ UN_InitTable(); /* Initializes front end */ /* SMD: Certain ports may have own command line options e.g. X version * FE_ will remove any options processed and update argc and argv. MA_ * can then check any options common to all platforms */ if (err = FE_InitSystem(&argc, argv)) { FE_DisplayError(err); exit(1); } /* NOTE: following can be erased if sound is already initialized in the * front end. * Commented it out for now */ /* SMD: Commenting out with #if 0 is useful coz you (and others) can find * it again easily. Also it lets you comment out code containing comments. * (Not really needed here, but a useful habit to get into.) */ /* Initializes sound driver */ #if 0 if (err = AS_InitSound(SoundDriver)) { printf("Could not init sound, error code=%i\n", err); exit(); } #endif /* show intro movie */ AS_ShowMovie(INTRO); go = 1; /* * from here on, go contains the game's state: * 0=quitting * 1=main menu * 2=paused */ while (go) { if (go == 1) { curmovie = 0; FE_DisplayScreen(MAINMENU); } else { FE_DisplayScreen(PAUSEMENU); } b1 = 0; while (!b1) { /* This also updates the pointer's screen representation, right? */ FE_PointerStatus(&x, &y, &b1, &b2); } /* if new game button is pressed */ if (MA_CheckButton(NEW, x, y)) { /* initialize game */ UN_InitGame(); /* start game */ if ((go = UN_PlayGame()) == 3) { /* SMD: This puts it in pause if the user says Don't Quit Is * that what we want? */ go = MA_ConfirmQuit(2); } } else /* if load game button is pressed */ if (MA_CheckButton(LOAD, x, y)) { /* load game dialog */ MA_LoadGame(); go = 2; } else /* if game is paused and save game button is pressed */ if ((go == 2) && MA_CheckButton(SAVE, x, y)) { /* save game dialog */ MA_SaveGame(); } else /* if game is paused and continue game button is pressed */ if ((go == 2) && MA_CheckButton(CONT, x, y)) { /* resume game */ go = UN_PlayGame(); } else /* if game is paused and replay movie button is pressed */ if ((go == 2) && MA_CheckButton(REP, x, y)) { /* replay last movie seen */ AS_ShowMovie(curmovie); } else /* if instructions button is pressed */ if (MA_CheckButton(INST, x, y)) { /* instructions movie is shown * Should this be a movie? Aren't scrollable * pages with text & graphics nicer? Or perhaps our * movie interface will be able to handle that kind of * stuff.. * The universe calls it a "movie". AS, FE, and the * end user may very well call it something else (like * scrolling pages with text and graphics). The key * idea is that the universe doesn't know or care what * happens when it plays a movie; it merely passes * control to the "movie player", which can be configured * for movies or text without having to fiddle with the * universe code. */ AS_ShowMovie(INSTRUCTIONS); } else /* if options button is pressed */ if (MA_CheckButton(OPT, x, y)) { /* enter options menu structure */ MA_Options(); } else /* if credits button is pressed */ if (MA_CheckButton(CRED, x, y)) { /* show credits movie */ AS_ShowMovie(CREDITS); } else /* if quit button is pressed */ if (MA_CheckButton(QUIT, x, y)) { /* show quit dialog */ go = MA_ConfirmQuit(go); } } /* end of WHILE loop */ /* show exit movie */ AS_ShowMovie(OUTRO); /* prepare game for shutdown */ UN_DeInitGame(); FE_DeInitSystem(); /* Bye! */ return 0; } From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:07:13 1995 Return-Path: Received: from hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmE8-000fJSC; Wed, 29 Nov 95 05:07 PST Received: from hpqs0123.sqf.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA029479939; Wed, 29 Nov 1995 04:59:01 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA166319938; Wed, 29 Nov 1995 12:58:58 GMT From: Stuart McDonald Message-Id: <199511291258.AA166319938@hpqs0123.sqf.hp.com> Subject: v0.6 as.h To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 12:58:58 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] #ifndef ARTSOUND_H_ #define ARTSOUND_H_ #include "universe.h" /* Description: * Type values for PlayFX (typedef anyone?) */ enum { FX_DIE=1, }; /* Description: */ typedef unsigned short AS_MovieNum; enum { INTRO=0, INSTRUCTIONS, CREDITS, OUTRO, GAME_OVER, PLAYER_WON }; /***************************** * Picture Struct ****************************/ /* * AS_Picture: * * temp - nothing * how should the sprite ptrs be stored? We need ptrs to the * overlays e.g. THRUST etc as well as the current frame */ typedef struct AS_Picture_s { long temp; } AS_Picture; /***************************** * Function Prototypes ****************************/ /* Description: * SMD: Not sure if this is needed. Think it does the same as GeneratePic ? */ void AS_InitializePic(UN_Object* obj); /* Description: * */ void AS_SetPic(AS_Picture *pic, long type); /* Description: * */ void AS_PlayFX(long type); /* Description: * */ void AS_ShowMovie(AS_MovieNum number); /* Description: * */ void AS_GeneratePic(UN_Object *obj); #endif From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:07:55 1995 Return-Path: Received: from relay.hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmEq-000fJUC; Wed, 29 Nov 95 05:07 PST Received: from hpqs0123.sqf.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA164429984; Wed, 29 Nov 1995 04:59:45 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA166429983; Wed, 29 Nov 1995 12:59:43 GMT From: Stuart McDonald Message-Id: <199511291259.AA166429983@hpqs0123.sqf.hp.com> Subject: v0.6 as.c To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 12:59:43 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] /***************************************************************************\ * Alife Game - as.c code file * * ------------------------------------------------------------------------- * * Copyright (C) 1995 Us. All Rights Reserved. * * ------------------------------------------------------------------------- * * Last Revised: 11/23/95 * * By: Stuart McDonald * * Version #: 0.60 * \***************************************************************************/ #include "as.h" #include "universe.h" /***************************** * Function Definitions ****************************/ /* Description: * */ void AS_InitializePic(UN_Object* obj) { AS_Picture *pNewPic; pNewPic = (AS_Picture*) malloc(sizeof(AS_Picture)); pNewPic->temp = 0; obj->pic = pNewPic; } /* Description: * */ void AS_SetPic(AS_Picture *pic, long type) { if (type & THRUSTPIC) { pic->temp = 0; } else if (type & BRAKEPIC) { pic->temp = 0; } if (type & TARGETPIC) { pic->temp = 0; } } /* Description: * */ void AS_PlayFX(long type) { switch (type) { case FX_DIE: break; } } /* Description: * */ void AS_ShowMovie(AS_MovieNum number) { switch (number) { case INTRO: case INSTRUCTIONS: case CREDITS: case OUTRO: case GAME_OVER: break; } } /* Description: * */ void AS_GeneratePic(UN_Object *obj) { AS_Picture *pNewPic; pNewPic = (AS_Picture*) malloc(sizeof(AS_Picture)); pNewPic->temp = 0; obj->pic = pNewPic; } From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:08:48 1995 Return-Path: Received: from hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmFg-000fJVC; Wed, 29 Nov 95 05:08 PST Received: from hpqs0123.sqf.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA030490036; Wed, 29 Nov 1995 05:00:38 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA166530035; Wed, 29 Nov 1995 13:00:35 GMT From: Stuart McDonald Message-Id: <199511291300.AA166530035@hpqs0123.sqf.hp.com> Subject: v0.6 fe.h To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 13:00:35 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] #ifndef FE_H_ #define FE_H_ #include "universe.h" /* For UN_Action */ /* SMD: Note: * (In theory) this header should _not_ contain any platform specific stuff, * it shouild define the interface to the FE_ that is used on all platforms. * So no function prototypes etc. for stuff needed on one platform and not * another. They go in the .c file. */ /* Description: * Number of universe points away that another object can be targetted at * defines a square area with side TARGET_RADIUS*2) * In FE since this should be probably be dependent on the player's view size */ #define TARGET_RADIUS 100 /* Description: * Values for various errors common to all platforms. ZERO = no error. * Comments: * Platform specific errors could begin at (say) 100 and be defined in fe.c. * SMD: Hmmm, does anyone else need to know about these, could they be local * to fe.c? */ /* SMD: Just some example values, not used */ typedef unsigned short FE_ErrorNum; enum { E_INITSYS=1, E_MEMORY }; /* Description: * Type to hold time for use by FE_ and AI_, i.e. when the next screen * update will take place. (AI_ use it to limit processing of probes) */ typedef unsigned long FE_Ticks; /* Description: * Screens used in FE_DisplayScreen(screen)) */ typedef unsigned short FE_ScreenNum; enum { MAINMENU=0, PAUSEMENU, CONFIRMQUITDIALOG }; /***************************** * Function Prototypes ****************************/ /* Description: * Routine to malloc memory. * Comments: * It is useful to have a wrapper around malloc for debugging, * for instance we can check for malloc failing etc. It's also * very easy to remove if we don't need it in the final version. * We could also add a parameter nonFatal which will allow us to * decide whether to return NULL or display an error and exit. */ void *FE_malloc(unsigned long mem); /* Description: * Get the keys pressed by the player. */ UN_Action FE_GetKeys(); /* Description: * Draw the screen and all the visibles objects etc. */ /* SMD: Changed Subsecoters var name to Sectors coz that makes more sense? */ /* SMD: Doesn't FE need the position within the subSector as well as the * X,Y of the subSector ? */ FE_Ticks FE_Update(UN_Object *(*Sectors)[NUMSUBS], unsigned short centerSubSectorX, unsigned short centerSubSectorY); /* Description: * SMD: Not sure who will call this, AS_? and can it be called during the * running of the game? */ char *FE_CompileSprite(char *source); /* Description: * Update the Pointer on the screen (if needed by this platform) and * return its position and buttons. */ void FE_PointerStatus(short* x, short* y, char* b1, char* b2); /* Description: * Display an error, (platform specific or otherwise). * SMD: Someone could have a think about the error system, coz I'm sure it * will start to get quite complex, e.g. do we want to abort the game, * return to main menu etc. (Do we want to start getting into using things * link setjmp and longjmp? Yuk!) */ void FE_DisplayError(FE_ErrorNum err); /* Description: * Display a screen such as MAINMENU, CONFIRMQUITDIALOG etc. */ void FE_DisplayScreen(FE_ScreenNum screenNum); /* Description: * Shutdown the system nicely. */ void FE_DeInitSystem(); /* Description: * Called when the UN_PlayGame starts to set when the next update * will take place. <<1>> * Returns: * When the next screen update will take place. */ FE_Ticks FE_Set(); /* Description: * Get the number of ticks (ie time) to the next update, given the time * of the next update */ FE_Ticks FE_GetTicks(FE_Ticks nextUpdate); /* Description: * SMD: What about a toggleMusic and toggleSFX? */ void FE_ToggleSound(); /* Description: * Initializes the platform specific parts. */ FE_ErrorNum FE_InitSystem(int *arg_ret, char *argv[]); /* * SMD: I can sort of see how this works, but I think AI_ will * have a hard time stopping probes from taking too long. Hmmmm, * mind you I spose they can run some sample code during the * initialize and see how long certain nodes take and use that * as a basis. Then the can just run so many commands for each * probe depending on how much time FE_ gives them. * Are we wanting the game to run at a fixed frame rate? It would * be best, but then AI_ gets less time when they most need it ie * alot happening) */ #endif From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:09:39 1995 Return-Path: Received: from relay.hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmGU-000fJXC; Wed, 29 Nov 95 05:09 PST Received: from hpqs0123.sqf.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA165270086; Wed, 29 Nov 1995 05:01:27 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA166640085; Wed, 29 Nov 1995 13:01:25 GMT From: Stuart McDonald Message-Id: <199511291301.AA166640085@hpqs0123.sqf.hp.com> Subject: v0.6 fe.c To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 13:01:24 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] /***************************************************************************\ * Alife Game - fe.c code file * * ------------------------------------------------------------------------- * * Copyright (C) 1995 Us. All Rights Reserved. * * ------------------------------------------------------------------------- * * Last Revised: 11/23/95 * * By: Stuart McDonald * * Version #: 0.60 * \***************************************************************************/ #include /* For stderr */ #include "main.h" /* For Button definitions */ #include "fe.h" #include "universe.h" /***************************** * Filescope Variables ****************************/ /* Description: * Pointer to argv[0] for error reporting */ /* SMD: Note on the PC argv[0] is the _full_ path name so will want to * strip off the path */ static char *progname; /***************************** * Function Definitions ****************************/ /* Description: * Routine to malloc memory. */ void *FE_malloc(unsigned long mem) { char *ptr = (char *) malloc(mem); if (ptr == NULL) { FE_DisplayError(E_MEMORY); } return (void *) ptr; } /* Description: * */ UN_Action FE_GetKeys() { return (UN_Action) THRUST; } /* Description: * */ FE_Ticks FE_Update(UN_Object *(*Sectors)[NUMSUBS], unsigned short centerSubSectorX, unsigned short centerSubSectorY) { return (FE_Ticks) 0; } /* Description: * */ char *FE_CompileSprite(char *source) { return source; } /* Description: * */ void FE_PointerStatus(short* x, short* y, char* b1, char* b2) { static ans[80]; printf("Which button do you want the pointer on?\n"); printf("NEW, REP, LOAD, CONT, INST, SAVE, OPT, CRED, QUIT, YES, NO\n"); scanf("%s",ans); if (strcmp(ans,"NEW") == 0) { *x = NEW_btn.ulx; *y = NEW_btn.uly; } else if (strcmp(ans,"REP") == 0) { *x = REP_btn.ulx; *y = REP_btn.uly; } else if (strcmp(ans,"LOAD") == 0) { *x = LOAD_btn.ulx; *y = LOAD_btn.uly; } else if (strcmp(ans,"CONT") == 0) { *x = CONT_btn.ulx; *y = CONT_btn.uly; } else if (strcmp(ans,"INST") == 0) { *x = INST_btn.ulx; *y = INST_btn.uly; } else if (strcmp(ans,"SAVE") == 0) { *x = SAVE_btn.ulx; *y = SAVE_btn.uly; } else if (strcmp(ans,"OPT") == 0) { *x = OPT_btn.ulx; *y = OPT_btn.uly; } else if (strcmp(ans,"CRED") == 0) { *x = CRED_btn.ulx; *y = CRED_btn.uly; } else if (strcmp(ans,"QUIT") == 0) { *x = QUIT_btn.ulx; *y = QUIT_btn.uly; } else if (strcmp(ans,"YES") == 0) { *x = YES_btn.ulx; *y = YES_btn.uly; } else if (strcmp(ans,"NO") == 0) { *x = NO_btn.ulx; *y = NO_btn.uly; } else { *x = 0; *y = 0; } *x += 1; *y += 1; /* So it's inside the button box */ *b1 = 1; *b2 = 1; } /* Description: * */ void FE_DisplayError(FE_ErrorNum err) { static char* errorStrs[] = { "Hey! This should never appear, coz error 0 is not an error!", "Yikes!" "MEMORY ERROR" }; fprintf(stderr,"%s: %s\n",progname,errorStrs[err]); } /* Description: * */ void FE_DisplayScreen(FE_ScreenNum screenNum) { switch (screenNum) { case MAINMENU: case PAUSEMENU: case CONFIRMQUITDIALOG: break; } } /* Description: * */ void FE_DeInitSystem() { } /* Description: * */ FE_Ticks FE_Set() { return (FE_Ticks) 0; } /* Description: * */ FE_Ticks FE_GetTicks(FE_Ticks nextUpdate) { return nextUpdate; } /* Description: * */ void FE_ToggleSound() { } /* Description: * Initializes the platform specific parts. * */ FE_ErrorNum FE_InitSystem(int *argc_ret, char *argv[]) { progname = argv[0]; return (FE_ErrorNum) 0; } From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:10:55 1995 Return-Path: Received: from hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmHh-000fJaC; Wed, 29 Nov 95 05:10 PST Received: from hpqs0123.sqf.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA032940161; Wed, 29 Nov 1995 05:02:42 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA166750160; Wed, 29 Nov 1995 13:02:40 GMT From: Stuart McDonald Message-Id: <199511291302.AA166750160@hpqs0123.sqf.hp.com> Subject: v0.6 alife.h To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 13:02:40 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] #ifndef ALIFE_H_ #define ALIFE_H_ #include "universe.h" #include "fe.h" /* For TicksLeft */ /* Description: * Maximum thrust possible for probe * Comments: * WARNING: currently completely arbitrary value, not yet * checked for. Only to give size of ThrustCost[] */ #define MAX_THRUST 100 /***************************** * Genome Struct ****************************/ /* * AI_Genome: * * long temp - Nothing */ typedef struct AI_Genome_s { long temp; } AI_Genome; /***************************** * Function Prototypes ****************************/ /* Description: */ void AL_InitPlayerGenome(UN_Object* obj); void AL_InitProbeGenome(UN_Object* obj, AI_Genome* parents); void AL_InitAsteroidGenome(UN_Object* obj); /* Description: * Gets the keys of the probe. An action is currently * a long with each bit reprsenting a key e.g. THRUST | LEFT | FIRE * (see universe.h for the #defines) */ UN_Action AI_GetKeys(UN_Object *obj); /* Description: * Tells the probe something e.g. THRUST_FAIL, FIRE_FAIL */ void AI_Interrupt(UN_Object *obj, long type); /* Description: * Does the actual AI stuff for all the probes */ void AI_DoQueue(FE_Ticks ticksLeft); #endif From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:12:07 1995 Return-Path: Received: from hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmIr-000fJcC; Wed, 29 Nov 95 05:12 PST Received: from hpqs0123.sqf.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA033320232; Wed, 29 Nov 1995 05:03:53 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA166860231; Wed, 29 Nov 1995 13:03:51 GMT From: Stuart McDonald Message-Id: <199511291303.AA166860231@hpqs0123.sqf.hp.com> Subject: v0.6 alife.c To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 13:03:51 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] /***************************************************************************\ * Alife Game - alife.c code file * * ------------------------------------------------------------------------- * * Copyright (C) 1995 Us. All Rights Reserved. * * ------------------------------------------------------------------------- * * Last Revised: 11/23/95 * * By: Stuart McDonald * * Version #: 0.60 * \***************************************************************************/ #include /* for definition of NULL */ #include "alife.h" #include "universe.h" /***************************** * Function Definitions ****************************/ /* Description: */ void AL_InitPlayerGenome(UN_Object* obj) { obj->extra.animate.gtype = (AI_Genome*)NULL; } /* Description: */ void AL_InitProbeGenome(UN_Object* obj, AI_Genome* parents) { obj->extra.animate.gtype = (AI_Genome*)parents; } /* Description: */ void AL_InitAsteroidGenome(UN_Object* obj) { obj->extra.animate.gtype = (AI_Genome*)NULL; } /* Description: * Gets the keys of the probe. An action is currently * a long with each bit reprsenting a key e.g. THRUST | LEFT | FIRE * (see universe.h for the #defines) */ UN_Action AI_GetKeys(UN_Object *obj) { if (obj->what == PROBE) return (UN_Action) THRUST; else return (UN_Action) BRAKE; } /* Description: * Tells the probe something e.g. THRUST_FAIL, FIRE_FAIL */ void AI_Interrupt(UN_Object* obj, long type) { switch (type) { case THRUST_FAIL: obj->extra.animate.actions &= !THRUST; break; default: return; } return; } /* Description: * Does the actual AI stuff for all the probes */ void AI_DoQueue(FE_Ticks ticksLeft) { if (ticksLeft == 0) ++ticksLeft; } From hpqs0130.sqf.hp.com!smd Wed Nov 29 05:21:41 1995 Return-Path: Received: from relay.hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKmS8-000fJbC; Wed, 29 Nov 95 05:21 PST Received: from hpqs0123.sqf.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA171700808; Wed, 29 Nov 1995 05:13:29 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA166970807; Wed, 29 Nov 1995 13:13:27 GMT From: Stuart McDonald Message-Id: <199511291313.AA166970807@hpqs0123.sqf.hp.com> Subject: v0.6 Comments To: ag-universe@krl.caltech.edu Date: Wed, 29 Nov 95 13:13:27 GMT Cc: ag-directors@krl.caltech.edu Mailer: Elm [revision: 70.85] Hi all, Argh what a week, work's been hell and I haven't got as much done to the code as I wanted. I'm mailing it anyway to universe and directors. There are files which relate to all groups e.g. as.h but since these as just stubs and to save bandwith I thought I'd just let the directors of each group deal with it. Sorry I aint got long to talk. Most of the changes are cosmetic, there are a few bug fixes and stuff. If you look for SMD: thats how I began comments about changes, bugs etc. The code should compile and even run, but don't expect it to do anything. The stub for pointerStatus lets you type in a string to say which button gets pressed (e.g NEW for new game), but I actually only tested NEW (in which case it sits running through the playgame loop and won't do anything [I was stepping through it with a debugger to check stuff ok]). I didnt have time to put in the AL stubs for the getproperty stuff etc. but I will try sometime soon. Though I have some questions about the indirection of the UN_ pointers for AL_ but I aint got time... _Gotta_ rush, Cheers, Stuart. -- Stuart McDonald :: HP - TSD SQF Scotland :: smd@hpsqf.sqf.hp.com 10 INPUT A " Aaah, the good old 20 INPUT B: POKE A,B: LET A = A + 1: GOTO 20 days..." From undergrad.math.uwaterloo.ca!jmlait Wed Nov 29 19:45:33 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKzw5-000fK9C; Wed, 29 Nov 95 19:45 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id WAA26002; Wed, 29 Nov 1995 22:37:15 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id WAA07842; Wed, 29 Nov 1995 22:37:13 -0500 Date: Wed, 29 Nov 1995 22:37:12 -0500 (EST) From: Jeff Lait To: Directors , FE-ALL , Art Sound Subject: fe.h Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII /****************************************************************** $Header$ Header: FE.H Author: Jeff Lait Copyright 1995 Project Von N*. Description: Contains definitions for all front end functions which are exported. ******************************************************************/ /****************************************************************** Revision Record Rev Date Auth Changes === ==== ==== ======= 0.0 29/11/95 jml created header ******************************************************************/ #ifndef FE_H #define FE_H /****************************************************************** * INCLUDES: ******************************************************************/ #include "universe.h" /****************************************************************** * DEFINES: ******************************************************************/ #define TARGET_RADIUS 100 /* Typedefs */ typedef unsigned short FE_ErrorNum; enum { E_NOERROR = 0, E_INITSYS, E_MEMORY }; typedef unsigned long FE_Ticks; typedef unsigned short FE_ScreenNum; enum { MAINMENU=0, PAUSEMENU, CONFIRMQUITDIALOG }; /****************************************************************** * FUNCTION PROTOTYPES ******************************************************************/ void *FE_Malloc(unsigned long mem); void FE_Free(void *mem); FE_ErrorNum FE_InitSystem(char *config); void FE_DeInitSystem(); void FE_InitScreen(); char *FE_CompileSprite(char *source); int FE_IsKey(char key); UN_Action FE_GetKeys(); FE_Ticks FE_GetTicks(FE_Ticks nextUpdate); void FE_ToggleSound(); FE_Ticks FE_Update(UN_Object *(*Subsectors)[NUMSUBS], unsigned long CenterSubSectorX, unsigned long CenterSubSectorY); void FE_PointerStatus(short* x, short* y, char* b1, char* b2); void FE_DisplayError(FE_ErrorNum err); void FE_DisplayScreen(FE_ScreenNum screenNum); void FE_DeInitSystem(); FE_Ticks FE_Set(); void FE_Test(char *ship, int angle); #endif - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed Nov 29 19:46:05 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKzwe-000fKAC; Wed, 29 Nov 95 19:46 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id WAA21052; Wed, 29 Nov 1995 22:37:51 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id WAA07923; Wed, 29 Nov 1995 22:37:49 -0500 Date: Wed, 29 Nov 1995 22:37:48 -0500 (EST) From: Jeff Lait To: FE-ALL , Directors , Art Sound Subject: femain.cpp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII /****************************************************************** $Header$ Module: FEMAIN.CPP Author: Jeff Lait Copyright 1995 Project Von N*. Description: This is all the FE-PCX code which can still be written in C due to it's lack of need for speed but still must be FE because it is implementation specific. Note that C++ style comments are used. Other than that, it should work on any flat memory model compiler for 80x86. ******************************************************************/ /****************************************************************** Revision Record Rev Date Auth Changes === ==== ==== ======= 0.0 23/10/95 jml created header. 0.1 29/11/95 jml merged in stubs from Stuart McDonald ******************************************************************/ /****************************************************************** * INCLUDES: ******************************************************************/ #include #include #include #include #include "feasm.h" // Asm funcs specific to this. #include "alife.h" // alife header. #include "main.h" // Main data. #include "as.h" // artsound header. #include "universe.h" // Contains UN_Object definition. #include "fe.h" // Standard FE header. /****************************************************************** * DEFINES: ******************************************************************/ // These defines will have to be made generic: #define SPRITEW 32 // `Tile size', currently onl used to determine #define SPRITEH 32 // how much of an overhang to do on edges of screen. #define VIRTW 12 // dimmensions of virtual screen in tiles. #define VIRTH 9 #define SPRITESZ SPRITEW*SPRITEH // Size of one tile in bytes. #define max(a,b) ((ab) ? (b) : (a)) #define abs(a) ((a < 0) ? (-(a)) : (a)) #define UNFIX(a) ((a)>>16) // Shouldn't be here :> // POINT_IN: Determines whether a point is inside square with top left at (0,0) #define POINT_IN(x, y, w, h) \ ((x > 0) && (x < w) && (y > 0) && (y < h)) #define NUM_STAR 500 // Make as large as desirable. #define STATE_Game // #define STATE_Testing // Internal FE key definitions: enum { FE_KEY_QUIT = 1, FE_KEY_THRUST, FE_KEY_LEFT, FE_KEY_RIGHT, FE_KEY_BRAKE }; /****************************************************************** * STRUCTURES: ******************************************************************/ /****************************************************************** * GLOBAL VARIABLES: ******************************************************************/ /****************************************************************** * LOCAL FUNCTION PROTOTYPES ******************************************************************/ char *GenerateSpriteCode(int width, int height, int angle); int *GenerateEdgeData(int width, int height, int angle); void FE_RedrawScreen(UN_Object *first, int nX, int nY, short *ticks); void AddStack(int *stack, int *stacklen, int destoff, int w, int h); void DoStack(int *stack, int *stacklen); /****************************************************************** * LOCAL VARIABLES: ******************************************************************/ int *xlookup, *ylookup; // Translation table between Universe coords & screen. // TBD once we get that straightened out. char keytable[128]; // 1 if scan code pressed, 0 else. char transtable[128]; // Tells us which key #defines go with what scan codes. char *virtscreen; // Virtual screen int DirtyStack[256*3]; // Stack of dirty rectangles to erase. int DirtyStackPos; // Where we are in that stack. int RedrawAllFlag = 0; // Currently unused as we redraw all anyways. int *rotatedata[256]; // Edge data for rotation code. // Format: Header: width/height, cos/sin // Element: src off, fract, dst off, dst width. int *stardata; // Star data for moving stars etc. // Format: Header: dx, dy // Element: X, Y, speed, colour int ticks = 0; // Current tick. /****************************************************************** * AddStack * This should probably make sure it doesn't add the same square twice. ******************************************************************/ void AddStack(int *stack, int *stacklen, int destoff, int w, int h) { stack[*stacklen] = (int) destoff; stack[*stacklen+1] = (int) w; stack[*stacklen+2] = (int) h; *stacklen += 3; } /****************************************************************** * DoStack ******************************************************************/ void DoStack(int *stack, int *stacklen) { int i1; for (i1 = 0; i1 < *stacklen;i1+=3) { FEASM_DrawSquare(&virtscreen[stack[i1]], stack[i1+1], stack[i1+2]); } *stacklen = 0; } /****************************************************************** * FE_Malloc * Currently a chain to normal malloc. Allows possible debug code * to be added. ******************************************************************/ void *FE_Malloc(unsigned long mem) { void *result; result = malloc(mem); if (!result) { FE_DisplayError(E_MEMORY); } return(result); } /****************************************************************** * FE_Free * Required complement to malloc. ******************************************************************/ void FE_Free(void *ptr) { free(ptr); } /****************************************************************** * FE_PointerStatus ******************************************************************/ void FE_PointerStatus(short* x, short* y, char* b1, char* b2) { // See need.txt for why I don't think this is correct. } /****************************************************************** * FE_DisplayError * Takes an error number, translates to string and writes to stdout. * For now crashes program. ******************************************************************/ void FE_DisplayError(FE_ErrorNum err) { switch (err) { case 0: FEASM_SetGraph(0x3); printf("Invalid call to FE_DisplayError\n"); exit(0); break; case E_MEMORY: FEASM_SetGraph(0x3); printf("Failure to allocate memory\n"); exit(E_MEMORY); break; default: FEASM_SetGraph(0x3); printf("Unknown error %d\n", err); exit(err); break; } } /****************************************************************** * FE_DisplayScreen * Currently, sets graph mode to text & writes text.. ******************************************************************/ void FE_DisplayScreen(FE_ScreenNum screenNum) { switch (screenNum) { case MAINMENU: FEASM_SetGraph(0x3); printf("At main menu!\n"); break; case PAUSEMENU: FEASM_SetGraph(0x3); printf("At pause menu!\n"); break; case CONFIRMQUITDIALOG: FEASM_SetGraph(0x3); printf("At confirm quit menu!\n"); break; } } /****************************************************************** * FE_Set * Shouldn't this be get????? ******************************************************************/ FE_Ticks FE_Set() { // TBD: Add timer code. return(ticks+10); } /****************************************************************** * FE_GetTicks ******************************************************************/ FE_Ticks FE_GetTicks(FE_Ticks nextUpdate) { return(nextUpdate - ticks); } /******************************************************************** * FE_Test * Does a cheap test of rotating ability: ********************************************************************/ void FE_Test(char *ship, int angle) { char *dest; dest = (char *) 0xa0000; dest += 100*320 + 160; FEASM_DrawRotated(dest, ship, rotatedata[angle]); // rotatedata[angle]); } /******************************************************************** * FE_InitSystem * The config file normally would tell us what res etc. For now, * we assume 320x200. ********************************************************************/ FE_ErrorNum FE_InitSystem(char *config) { int i1; if (config) i1 = 0; // Ignore... // Create look up tables... xlookup = (int *) FE_Malloc(1024 * sizeof(int)); ylookup = (int *) FE_Malloc(768 * sizeof(int)); if (!(ylookup || xlookup)) { // Error... We still need common error recovery! } // Fill tables: (This is not currently used until we decide on a scale... for (i1 = 0; i1 < 1024; i1++) { xlookup[i1] = (int) ((double) i1 / 1024 * 320); } for (i1 = 0; i1 < 768; i1++) { ylookup[i1] = (int) ((double) i1 / 768 * 200); } // Erase keypress table: memset(keytable, 0, 128); // Set translation table to 1-1 correspondence. More on this later. for (i1 = 0; i1 < 128; i1++) { transtable[i1] = (char) i1; } // Finish setting it up (By scan codes:->) transtable[FE_KEY_QUIT] = 1; // Esc. transtable[FE_KEY_THRUST] = 72; // Up. transtable[FE_KEY_LEFT] = 75; // left. transtable[FE_KEY_RIGHT] = 77; // right. transtable[FE_KEY_BRAKE] = 80; // Break. // Allocate virtual screen: virtscreen = (char *) FE_Malloc(SPRITESZ * VIRTW * VIRTH); memset(virtscreen, 0, SPRITESZ * VIRTW * VIRTH); // Generate edge table: for (i1 = 0; i1 < 256; i1++) { rotatedata[i1] = GenerateEdgeData(SPRITEW, SPRITEH, i1); } // Initialize stars: stardata = (int *) FE_Malloc(sizeof(int) * (NUM_STAR * 4 + 2)); stardata[0] = 0; stardata[1] = 0; FEASM_InitStars(0x1234678, NUM_STAR, stardata); // Grab ints etc: FEASM_Init(xlookup, ylookup, keytable); return(E_NOERROR); } /******************************************************************** * FE_DeInitSystem * Frees memory, kills vectors. ********************************************************************/ void FE_DeInitSystem() { int i1; FEASM_SetGraph(0x3); free(xlookup); free(ylookup); free(virtscreen); for (i1 = 0; i1 < 256; i1++) { free(rotatedata[i1]); } FEASM_ShutDown(); } /******************************************************************** * FE_InitScreen * Sets the screen res etc. ********************************************************************/ void FE_InitScreen() { FEASM_SetGraph(0x13); // Fill dirty stack with entire screen: RedrawAllFlag = 1; } /******************************************************************** * FE_CompileSprite * Takes a 128x128x256c (No colour look up for now...) * image & converts it to our own internal size. * Need a better sprite memory manager, as each sprite needs to be 256 wide, * ie: interleave 4 32 wide sprites together or something similar. ********************************************************************/ char *FE_CompileSprite(char *source) { char *dest, *temp; int i1, i2; dest = (char *) FE_Malloc(256 * SPRITEH); if (!dest) { return(dest); } temp = dest; for (i1 = 0; i1 < SPRITEH; i1++) { for (i2 = 0; i2 < SPRITEW; i2++) { *temp++ = *source; source += 4; } temp += 256 - SPRITEW; source += 128*3; // get to next line... } return(dest); } /******************************************************************** * FE_IsKey * Tells whether a given key code has been pressed. * Basically, looks up in table of key codes for the scan code requested, * and checks if that scan code has been pressed. ********************************************************************/ int FE_IsKey(char key) { return(keytable[transtable[key]]); } /****************************************************************** * FE_GetKeys * Calls FE_IsKey to build action variable ******************************************************************/ UN_Action FE_GetKeys() { int result = 0; // What are the codes??? if (FE_IsKey(transtable[FE_KEY_QUIT])) result |= KEY_QUIT; if (FE_IsKey(transtable[FE_KEY_THRUST])) result |= THRUST; if (FE_IsKey(transtable[FE_KEY_LEFT])) result |= LEFT; if (FE_IsKey(transtable[FE_KEY_RIGHT])) result |= RIGHT; if (FE_IsKey(transtable[FE_KEY_BRAKE])) result |= BRAKE; return( result ); } /****************************************************************** * FE_GetTicks * TBD! ******************************************************************/ FE_Ticks FE_GetTicks() { return(-1); } /****************************************************************** * FE_ToggleSound ******************************************************************/ void FE_ToggleSound() { return; } /****************************************************************** * FE_Update * TBD: Move star code into here... ******************************************************************/ FE_Ticks FE_Update(UN_Object *(*Subsectors)[NUMSUBS], unsigned long CenterSubSectorX, unsigned long CenterSubSectorY) { short ticks = 0; unsigned int subx, suby, nextsubx, nextsuby; // Which subsector... // Call redraw: Find upper left: subx = CenterSubSectorX - VIRTW * SPRITEW * 65536 / 2; suby = CenterSubSectorY - VIRTH * SPRITEH * 65536 / 2; subx >>= 26; suby >>= 26; // Was this X,Y or Y,X??? FE_RedrawScreen(Subsectors[suby][subx], CenterSubSectorX, CenterSubSectorY, &ticks ); // Is left side different? nextsubx = CenterSubSectorX + VIRTW * SPRITEW * 65536 / 2; nextsubx >>= SUBPOWER; if (nextsubx != subx) { FE_RedrawScreen(Subsectors[suby][nextsubx], CenterSubSectorX, CenterSubSectorY, &ticks ); } nextsuby = CenterSubSectorY + VIRTH * SPRITEH * 65536 / 2; nextsuby >>= SUBPOWER; if (nextsuby != suby) { FE_RedrawScreen(Subsectors[nextsuby][subx], CenterSubSectorX, CenterSubSectorY, &ticks ); } if ((nextsuby != suby) && (nextsubx != subx)) { FE_RedrawScreen(Subsectors[nextsuby][nextsubx], CenterSubSectorX, CenterSubSectorY, &ticks ); } // Okay, backdrop drawn, ships blitted, now actually blit the screen: FEASM_BlitScreen((char *) 0xa0000, &virtscreen[SPRITEH*VIRTW*SPRITEW + SPRITEW], VIRTW*SPRITEW-320); return( ticks ); } /******************************************************************** * FE_RedrawScreen * This has yet to be finalized. Takes a linked list of objects to * read (And a rather pathetic object definition to boot) ********************************************************************/ void FE_RedrawScreen(UN_Object *first, int nX, int nY, short *ticks) { int offx, offy; UN_Object *cur; static int oX = -1, oY = -1; // First, clear dirty stack: DoStack(DirtyStack, &DirtyStackPos); // Find new upper left... // This must be changed to accomadate actual Universe code // (Which is still being debated :> nX = nX - VIRTW * SPRITEW * 65536 / 2; nY = nY - VIRTH * SPRITEH * 65536 / 2; if (oX == -1) oX = nX; if (oY == -1) oY = nY; stardata[0] = (oX - nX) >> 2; // Stars move only as fast as stationary stardata[1] = (oY - nY) >> 2; // Objects.. Remove, cool effect :> FEASM_MoveStars(virtscreen, NUM_STAR, stardata); oX = nX; oY = nY; // We've now redrawn all the floor and (sX, oY) == (nX, nY). // Now, draw all the ships for (cur = first; cur; cur = cur->next_ob) { // Get position of this object: offx = rotatedata[cur->facdir & 255][0]/2+1; offy = rotatedata[cur->facdir & 255][1]/2+1; nX = UNFIX(cur->x - oX); nY = UNFIX(cur->y - oY); if ((nX > offx) && (nX < VIRTW*SPRITEW - offx) && (nY > offy) && (nY < VIRTH*SPRITEH - offy)) { AddStack(DirtyStack, &DirtyStackPos, (nX-1)+(nY-1)*VIRTW*SPRITEW, rotatedata[cur->facdir & 255][0] + 1, rotatedata[cur->facdir & 255][1] + 1); // Remove off by one error! FEASM_DrawRotated(&virtscreen[nX+nY*VIRTW*SPRITEW],cur->pic->curpic, rotatedata[cur->facdir & 255]); } } // All drawn... Normally retrieve tick count, but that timer not yet // added. *ticks = 0; } /******************************************************************** * GenerateEdgeData * This will generate the appropriate edge data for the rotate code. ********************************************************************/ int *GenerateEdgeData(int width, int height, int angle) { int dxx, dxy, dyx, dyy; // Deltas, (dest:source) int sx, sy; // Source position: 16:16. int osx, osy; // Source position: 16:16, original int dx, dy; // destination position: normal. int dw, dh; // destination width/height. int i1, i2; // Scratch. int *code, *ret; int codelen = 0; int edioff = 0; // Current edi offset. int binit = 0; code = (int *) FE_Malloc(64000); // Temporary buffer. if (!code) return(code); // Okay, first, find destination width/height. i1 = width; // Remember: we draw from centre!!! i2 = height; dxx = UN_cos[-angle]*65536; dxy = UN_sin[-angle]*65536; dyx = dxy; dyy = -dxx; dw = (abs(i1*dxx) + abs(i2*dxy)) >> 16; dh = (abs(i1*dyx) + abs(i2*dyy)) >> 16; // Find widths of dest. // Write header: code[codelen++] = dw; code[codelen++] = dh; code[codelen++] = dxx; code[codelen++] = dxy; // Cos/Sin values used for stepping over map. // Init sx, sy. osx = -dw/2 * UN_cos[-angle]*65536 - dh/2 * UN_sin[-angle]*65536 + (width/2 * 65536); osy = -dw/2 * UN_sin[-angle]*65536 + dh/2 * UN_cos[-angle]*65536 + (height/2 * 65536); for (dy = -dh/2; dy < -dh/2 + dh; dy++) { sx = osx; sy = osy; for (dx = 0; dx < dw && !POINT_IN((sx>>16), (sy>>16), width, height); dx++) { sx += dxx; sy += dxy; } // Write src offset code[codelen++] = (sx >> 16); // Write fractional source offset: Contains real sy value as well!!! code[codelen++] = ((sx & 0xffff) << 16) + ((sy >> 8) & 0xffff); // write dest offset: code[codelen++] = dx; for (; dx < dw && POINT_IN((sx>>16), (sy>>16), width, height); dx++) { sx += dxx; sy += dxy; } // write width: code[codelen] = dx - code[codelen-1]; codelen++; osx += dyx; osy += dyy; } // End for dy=-dh/2..dh/2 if (codelen > 64000/sizeof(int)) { // This should NOT happen!!! } // Create smaller version to return: ret = (int *) FE_Malloc(codelen*sizeof(int)); if (!ret) { free(code); return(NULL); } memcpy(ret, code, codelen*sizeof(int)); free(code); return(ret); } - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed Nov 29 19:47:16 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKzxk-000fKBC; Wed, 29 Nov 95 19:47 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id WAA17285; Wed, 29 Nov 1995 22:38:59 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id WAA08072; Wed, 29 Nov 1995 22:38:57 -0500 Date: Wed, 29 Nov 1995 22:38:56 -0500 (EST) From: Jeff Lait To: Directors , FE-ALL , Art Sound Subject: fegcc.asm Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ;********************************************************************* ; FEASM.ASM ; This contains the ASM functions required by FEPCX. ; Compiles under TASM 3.0 with the switches specified in the makefile. ; This version assumes stack calling convention, in order to work ; properly with gcc. It also reverses the _direction. ; DATA directive may be incorrect. ;********************************************************************* ; Copyright 1995 by Jeff Lait. ; Permission granted to members of the A-Life team to hack/modify at ; their whim :> ;********************************************************************* ; Notes: ; This current version is for 320x200. It basically does all writes to ; an offscreen buffer which is then blitted over via BlitScreen. ; A VESA version will probably use page flipping and do all writes directly ; on screen to reduce bandwidth... ; The timer isn't yet hooked in. ;********************************************************************* .386p ;********************************************************************* ; Functions: ;********************************************************************* public _FEASM_DrawSquare ; dest, width, height. public _FEASM_Init ; x, ylookup, keytable. public _FEASM_Shutdown public _FEASM_DrawTransSquare ; dest, source public _FEASM_SetGraph ; int mode public _FEASM_BlitScreen ; int dest, int source, int skip ; 3761 FPS for 32x32 trans. public _FEASM_DrawRotated ; int dest, int source, int *edgedata public _FEASM_MoveStars ; int dest,int numstars,int *stardata public _FEASM_InitStars ; int seed, int num, int *data _DATA segment para public use32 'DATA' ;********************************************************************* ; EQUATES ;********************************************************************* SPRITEW = 32 SPRITEH = 32 VIRTW = 12 VIRTH = 9 SPRITESZ = 1024 ;********************************************************************* ; DATA ;********************************************************************* keytable DD ? xlookup DD ? ylookup DD ? OldKeyOff DD ? OldKeySeg DW ? Random DD 12345678h ;********************************************************************* ; Jump table used by unrolled loop: ;********************************************************************* JumpTable520: DD offset Jump0Table520 DD offset Jump1Table520 DD offset Jump2Table520 DD offset Jump3Table520 ;********************************************************************* ; Multiplication lookup. Hey, there must be a better way to generate ; this under TASM 3.0 - Any suggestions??? ;********************************************************************* DDMultTable: ; Probably better way to write this... IRP @M41, <0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31> IRP @M42, <0, 1, 2, 3, 4, 5, 6, 7, 8> DD VIRTW*SPRITEW*(@M41*9 + @M42) ENDM ENDM _DATA ends ;********************************************************************* ; CODE ;********************************************************************* _TEXT segment para public use32 'CODE' assume cs:_TEXT, ds:_DATA, es:_DATA ;********************************************************************* ; MACROS ;********************************************************************* ;********************************************************************* ; TRANS_MOVE ; Does a transparent move from source to dest of 4 bytes. ;********************************************************************* TRANS_MOVE MACRO dest, source mov eax, [source] mov edx, eax sub dl, 1 sbb dl, dl ; Set DL to carry. sub dh, 1 sbb dh, dh rol edx, 16 ; Screw 386's... ; bswap edx ; Faster, but screws 386s. sub dl, 1 sbb dl, dl sub dh, 1 sbb dh, dh rol edx, 16 ; bswap edx and edx, [dest] or eax, edx mov [dest], eax ENDM ;********************************************************************* ; FUNCTIONS ;********************************************************************* ;********************************************************************* ; RandomDelta ; Sets EAX to a random delta. ; This generator was ripped from BC++ 3.0 ;********************************************************************* RandomDelta proc push edx ecx ebx mov ecx, 15a4e35h mov eax, Random mul ecx shrd eax, edx, 16 inc eax mov ebx, eax ; Top 16 random... mul ecx shrd eax, edx, 16 inc eax mov Random, eax shrd ebx, edx, 16 mov eax, ebx pop ebx ecx edx ret RandomDelta endp ;********************************************************************* ; FEASM_SetGraph - Called with ; v FEASM_SetGraph(int mode); ; EAX ; TBD: Make VESA compliant. ;********************************************************************* _FEASM_SetGraph proc mov eax, [esp+4] int 10h ret _FEASM_SetGraph endp ;********************************************************************* ; FEASM_Init - Called with ; v FEASM_Init(char *x, char *ylookup, char *keytable); ; EAX EDX EBX ;********************************************************************* _FEASM_Init proc mov eax, [esp+4] push ebx edx mov edx, [esp+16] mov ebx, [esp+20] mov xlookup, eax mov ylookup, edx mov keytable, ebx ; Save the DS so anyone can get it: push eax ebx ecx es xor ebx, ebx mov bx, cs mov eax, 0ah ; Create Alias. int 31h ; Should jump off on error (CF set) mov bx, ds mov es, ax mov ecx, offset OurDS mov es:[ecx], bx pop es ; Free selector: mov ebx, eax mov eax, 1 int 31h ; Again, check error code. pop ecx ebx eax ; Done... ; Should hook vectors: push esi edi ebx ecx es mov eax, 3409h int 21h ; get old int into es:bx mov OldKeySeg, es mov OldKeyOff, ebx pop es mov edi, keytable xor eax, eax mov ecx, 32 rep stosd ; Clear interrup table. mov eax, 2509h mov edx, offset int9 push ds cs pop ds int 21h ; Set the vector. pop ds ; Should now set the ticker & reset its speed... pop ecx ebx edi esi pop edx ebx ret _FEASM_Init endp ;********************************************************************* ; FEASM_Shutdown - Called with ; v FEASM_Shutdown(); ;********************************************************************* _FEASM_Shutdown proc push eax edx ecx ebx es ds mov edx, OldKeyOff mov ds, OldKeySeg mov eax, 2509h int 21h ; reset int handler. pop ds es ebx ecx edx eax ret _FEASM_Shutdown endp ; Ugly, but works: OurDS DW ? ;********************************************************************* ; Interrupt handlers: Pretty self evident. ;********************************************************************* int9 proc push eax edx ecx ebx ds ; Get data segment: mov ax, cs:OurDS mov ds, ax ; Get scan code & control: in al, 60h ; DEBUG: mov ebx, 0b0000h inc BYTE PTR [ebx] mov BYTE PTR [ebx+2], al ; END DEBUG xor ebx, ebx mov bl, al ; Save scan code. xchg al, ah or al, 80h ; Set keyboard acknowledge... inc dx out dx, al ; Acknowledge keypress! test bl, 80h ; Is it release? jnz ZeroCharacter add ebx, keytable mov BYTE PTR [ebx], 1 ; Char is pressed. jmp Skip143 ZeroCharacter: and bl, 7fh add ebx, keytable mov BYTE PTR [ebx], 0 Skip143: ; Reset keyboard: in al, 61h or al, 80h out 61h, al and al, 7fh out 61h, al mov al, 20h ; Send generic EOI to PIC. out 20h, al pop ds ebx ecx edx eax iretd ; Pus... Wasted half an hour before I noticed this :> int9 endp ; NB: How can you get Watcom debugger to save it's ; interrupts so you don't lose the kbd?? ;********************************************************************* ; FEASM_DrawSquare - Called as ; v FEASM_DrawSquare(char *dest, int w, int h); ; EAX EDX EBX ; Fills in a black rectangle centred at dest, of wxh dimmensions. ;********************************************************************* _FEASM_DrawSquare proc mov eax, [esp+4] push edx ebx mov edx, [esp+16] mov ebx, [esp+20] push ecx edi mov edi, eax add edx, 3 shr edx, 1 sub edi, edx shr edx, 1 mov eax, ebx shr eax, 1 sub edi, [eax*4 + offset DDMultTable] xor eax, eax StartLoop231: push edi ; Ugh... mov ecx, edx rep stosd pop edi add edi, VIRTW*SPRITEW dec ebx jnz StartLoop231 pop edi ecx pop ebx edx ret _FEASM_DrawSquare endp ;********************************************************************* ; FEASM_DrawTransSquare - called as ; v FEASM_DrawTransSquare(char *dest, char *source); ; EAX EDX ; Not used now. Draws a transparent square. Could be adapted form ; blitting transparent objects (Though allignment checks, at 3 cycles ; per misallignment, are a must :>) ;********************************************************************* _FEASM_DrawTransSquare proc mov eax, [esp+4] mov edx, [esp+8] push esi edi mov esi, edx mov edi, eax REPT SPRITEH ;; Should be dependent upon SPRITEW IRP @M130, <0, 4, 8, 12, 16, 20, 24, 28> TRANS_MOVE [edi+@M130], [esi+@M130] ENDM add esi, SPRITEW add edi, SPRITEW*VIRTW ENDM pop edi esi ret _FEASM_DrawTransSquare endp ;********************************************************************* ; FEASM_BlitScreen - called with ; v FEASM_BlitScreen(char *dest, char *source, int skip); ; EAX EDX EBX ;********************************************************************* _FEASM_BlitScreen proc mov eax, [esp+4] push edx ebx mov edx, [esp+16] mov ebx, [esp+20] push esi edi ecx mov edi, eax mov esi, edx mov eax, 200 ; Should be made generic. Loop225: mov ecx, 80 rep movsd add esi, ebx dec eax jnz Loop225 pop ecx edi esi pop ebx edx ret _FEASM_BlitScreen endp ;********************************************************************* ; FEASM_InitStars(int seed, int numstar, int *stardata); ; EAX EDX EBX ; Randomizes positions & speeds of all stars. ;********************************************************************* _FEASM_InitStars proc mov eax, [esp+4] push ebx edx mov ebx, [esp+16] mov edx, [esp+20] push esi edi ecx mov ecx, edx mov esi, ebx add esi, 8 mov Random, eax StartLoop292: call RandomDelta xor edx, edx mov ebx, VIRTW*SPRITEW*65536 div ebx mov [esi], edx ; X call RandomDelta xor edx, edx mov ebx, VIRTH*SPRITEW*65536 div ebx mov [esi+4], edx ; Y call RandomDelta and eax, 03ffffh mov [esi+8], eax ; Speed shr eax, 14 add eax, 16 mov [esi+12], eax ; Colour. add esi, 16 dec ecx jnz StartLoop292 pop ecx edi esi pop edx ebx ret _FEASM_InitStars endp ;********************************************************************* ; FEASM_MoveStars(int dest, int numstar, int *stardata); ; EAX EDX EBX ; Star Format: ; Header: DD dX, dY ; Element:DD X, Y, Speed, Colour ; NB: Not perfect, a trailing star can be masked by a leading one, but ; to avoid this would take two passes which would probably not be worth it. ; Problems in VESA: Keep stars in seperate banks: Crossovers should be throwns ; on a crossover stack for dealing with afterwards. ;********************************************************************* _FEASM_MoveStars proc mov eax, [esp+4] push edx ebx mov edx, [esp+16] mov ebx, [esp+20] push esi edi ecx ebp mov edi, eax mov esi, ebx mov ecx, edx mov ebx, [esi] ; dX mov ebp, [esi+4] ; dY add esi, 8 jmp LoopTest265 StartLoop266: mov edx, [esi+4] ; Y mov eax, [esi] ; X shr edx, 16 shr eax, 16 add eax, [edx*4 + offset DDMultTable] ; Offset of star... mov BYTE PTR [edi+eax], 0 ; Clear star... (AGI!) ; Update star pos: ; TBD: Optimize for jmp pred. if req'd. mov eax, [esi+8] ; Speed. imul ebx ; dx... shld edx, eax, 16 ; Actual dx... add edx, [esi] ; X jns Skip282 ; Negative: add edx, VIRTW*SPRITEW*65536 call RandomDelta and eax, 03ffffh mov [esi+8], eax ; New dY. shr eax, 14 ; Brighter: closer. Gives 0-16. add eax, 16 mov [esi+12], eax ; New colour. Skip282: cmp edx, VIRTW*SPRITEW*65536 jb Skip287 sub edx, VIRTW*SPRITEW*65536 call RandomDelta and eax, 03ffffh mov [esi+8], eax ; New dY. shr eax, 14 ; Brighter: closer. Gives 0-16. add eax, 16 mov [esi+12], eax ; New colour. Skip287: mov [esi], edx ; Save X... ; Now Y: mov eax, [esi+8] ; Speed. imul ebp ; dY shld edx, eax, 16 add edx, [esi+4] ; Y. jns Skip302 add edx, VIRTH*SPRITEH*65536 call RandomDelta and eax, 03ffffh mov [esi+8], eax ; New dY. shr eax, 14 ; Brighter: closer. Gives 0-16. add eax, 16 mov [esi+12], eax ; New colour. Skip302: cmp edx, VIRTH*SPRITEH*65536 jb Skip311 sub edx, VIRTH*SPRITEH*65536 call RandomDelta and eax, 03ffffh mov [esi+8], eax ; New dY. shr eax, 14 ; Brighter: closer. Gives 0-16. add eax, 16 mov [esi+12], eax ; New colour. Skip311: mov [esi+4], edx ; Write new star at current pos: mov eax, [esi] mov edx, [esi+4] shr edx, 16 shr eax, 16 add eax, [edx*4 + offset DDMultTable] mov edx, [esi+12] mov BYTE PTR [edi+eax], dl ; Finish: add esi, 16 LoopTest265: dec ecx jnz StartLoop266 pop ebp ecx edi esi pop ebx edx ret _FEASM_MoveStars endp ;********************************************************************* ; FEASM_DrawRotated - called with ; v FEASM_DrawRotated(int dest, int source, int *edgedata ; EAX EDX EBX ; Does a simplified t-mapper using precompiled edge data. ; There appears to be an offby one error either in here or in the ; edge data compiler... ; Times are measured in 32x32 ships per 20 seconds. ; Not Unrolled, w/ pushes: 117053. ; Unrolled by 4, w/ pushes: 130657. ; Unrolled by 4, removed transparcency jump: ~43000: Ouch!!! ;********************************************************************* _FEASM_DrawRotated proc mov eax, [esp+4] push edx ebx mov edx, [esp+16] mov ebx, [esp+20] push esi edi ecx ebp ; Set up: ; Set proper destination: mov edi, eax mov eax, [ebx+4] ; Height shr eax, 1 mov eax, [eax*4 + offset DDMultTable] add eax, eax add eax, [ebx] ; Width shr eax, 1 sub edi, eax ; Set up source: mov esi, edx ; Set up increments: mov ax, [ebx+10] cwde mov ebp, eax ; High dxx. mov eax, [ebx+6] ; Load high eax with low cos. mov ax, [ebx+13] ; ah = lowhigh byte of sin, al = high low. ; Get past header. add ebx, 16 ; Set up y loop vars: mov ecx, [ebx-12] ; Height. ; Argh.. This loop is disgustingly unefficient... StartLoop290: push edi esi ebx ecx ; Should store or S-M or something else. add esi, [ebx] add edi, [ebx+8] mov ecx, [ebx+12] mov edx, ecx add ecx, 3 and edx, 3 shr ecx, 2 jmp DWORD PTR [edx*4 + offset JumpTable520] Jump0Table520: mov edx, [ebx+4] xor ebx, ebx jcxz End314 ; Occasionaly, really is zero! jmp Unrolled0Loop275 Jump1Table520: mov edx, [ebx+4] xor ebx, ebx sub edi, 3 jmp Unrolled1Loop275 Jump2Table520: mov edx, [ebx+4] xor ebx, ebx sub edi, 2 jmp Unrolled2Loop275 Jump3Table520: mov edx, [ebx+4] xor ebx, ebx dec edi jmp Unrolled3Loop275 StartLoop275: Unrolled0Loop275: add edx, eax mov bh, [esi+ebx] ; No AGI - HAHAHA!!! adc esi, ebp or bh, bh jz Skip270 mov [edi], bh Skip270: mov bh, dh Unrolled3Loop275: add edx, eax mov bh, [esi+ebx] ; No AGI. adc esi, ebp or bh, bh jz Skip566 mov [edi+1], bh Skip566: mov bh, dh Unrolled2Loop275: add edx, eax mov bh, [esi+ebx] ; No AGI. adc esi, ebp or bh, bh jz Skip575 mov [edi+2], bh Skip575: mov bh, dh Unrolled1Loop275: add edx, eax mov bh, [esi+ebx] ; No AGI. adc esi, ebp or bh, bh jz Skip584 mov [edi+3], bh Skip584: mov bh, dh ; End... add edi, 4 dec ecx jnz StartLoop275 End314: pop ecx ebx esi edi add ebx, 16 add edi, VIRTW*SPRITEW ; add edi, 320 dec ecx jnz StartLoop290 ; Should now be done... pop ebp ecx edi esi pop ebx edx ret FEASM_DrawRotated_ endp ends _TEXT end - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed Nov 29 19:47:45 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKzyD-000fKDC; Wed, 29 Nov 95 19:47 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id WAA05638; Wed, 29 Nov 1995 22:39:28 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id WAA08137; Wed, 29 Nov 1995 22:39:26 -0500 Date: Wed, 29 Nov 1995 22:39:25 -0500 (EST) From: Jeff Lait To: Directors , FE-ALL , Art Sound Subject: as.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII /***************************************************************************\ * Alife Game - as.c code file * * ------------------------------------------------------------------------- * * Copyright (C) 1995 Us. All Rights Reserved. * * ------------------------------------------------------------------------- * * Last Revised: 11/23/95 * * By: Stuart McDonald * * Version #: 0.60 * \***************************************************************************/ #include "as.h" #include "fe.h" #include "universe.h" #include /* NULL. */ /***************************** * Function Definitions ****************************/ /* Description: * */ void AS_InitializePic(UN_Object* obj) { if (!obj->pic) { obj->pic = (AS_Picture*) FE_Malloc(sizeof(AS_Picture)); obj->pic->curpic = NULL; obj->pic->thrustpic = NULL; obj->pic->brakepic = NULL; obj->pic->targetpic = NULL; } } /* Description: * */ void AS_SetPic(AS_Picture *pic, long type) { if (type & THRUSTPIC) { pic->curpic = pic->thrustpic; } else if (type & BRAKEPIC) { pic->curpic = pic->brakepic; } if (type & TARGETPIC) { pic->curpic = pic->targetpic; } } /* Description: * */ void AS_PlayFX(long type) { switch (type) { case FX_DIE: break; } } /* Description: * */ void AS_ShowMovie(AS_MovieNum number) { switch (number) { case INTRO: case INSTRUCTIONS: case CREDITS: case OUTRO: case GAME_OVER: break; } } /* Description: * */ void AS_GeneratePic(UN_Object *obj) { AS_Picture *pNewPic; char *newdata; if( !obj->pic ) AS_InitializePic(obj); pNewPic = obj->pic; /* Temporary: create empty picture of random value... */ newdata = (char *) FE_Malloc( 128*128 ); pNewPic->thrustpic = FE_CompileSprite(newdata); FE_Free(newdata); pNewPic->curpic = pNewPic->thrustpic; pNewPic->targetpic = pNewPic->thrustpic; pNewPic->brakepic = pNewPic->thrustpic; } - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed Nov 29 19:48:15 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tKzyl-000fKEC; Wed, 29 Nov 95 19:48 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id WAA17661; Wed, 29 Nov 1995 22:40:02 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id WAA08234; Wed, 29 Nov 1995 22:39:58 -0500 Date: Wed, 29 Nov 1995 22:39:58 -0500 (EST) From: Jeff Lait To: Art Sound , FE-ALL , Directors Subject: as.h Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII #ifndef ARTSOUND_H_ #define ARTSOUND_H_ #include "universe.h" /* Description: * Type values for PlayFX (typedef anyone?) */ enum { FX_DIE=1, }; /* Description: */ typedef unsigned short AS_MovieNum; enum { INTRO=0, INSTRUCTIONS, CREDITS, OUTRO, GAME_OVER, PLAYER_WON }; /***************************** * Picture Struct ****************************/ /* * AS_Picture: * * temp - nothing * how should the sprite ptrs be stored? We need ptrs to the * overlays e.g. THRUST etc as well as the current frame */ typedef struct AS_Picture_s { char *curpic; /* Current picture to be displayed */ /* Add here some data structure describing other possible pics. */ /* Temporary: */ char *thrustpic; char *brakepic; char *targetpic; } AS_Picture; /***************************** * Function Prototypes ****************************/ /* Description: * SMD: Not sure if this is needed. Think it does the same as GeneratePic ? * JML: No, Initialize creates a picture field in the object, GeneratePic * would create the pictures inside the picture structure, no? */ void AS_InitializePic(UN_Object* obj); /* Description: * */ void AS_SetPic(AS_Picture *pic, long type); /* Description: * */ void AS_PlayFX(long type); /* Description: * */ void AS_ShowMovie(AS_MovieNum number); /* Description: * */ void AS_GeneratePic(UN_Object *obj); #endif - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed Nov 29 19:51:56 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tL02K-000fKGC; Wed, 29 Nov 95 19:51 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id WAA00788; Wed, 29 Nov 1995 22:43:43 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id WAA08897; Wed, 29 Nov 1995 22:43:39 -0500 Date: Wed, 29 Nov 1995 22:43:38 -0500 (EST) From: Jeff Lait To: Art Sound , FE-ALL , Directors Subject: Comments: Please read! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Okay, I've got it compiling and linking and almost running. The files I've sent out are: as.c as.h fe.h fegcc.asm femain.cpp If you are missing any, please let me know. Could someone in the universe team please look into the changes outlined below: 1) UN_Cos & UN_Sin - Weren't these going to be fixed point? It kind of defeats the purpose to make a table of float values.... 2) FE_PointerStatus: Shouldn't buttons etc, be interrupt based? For example, to use this one needs a tight loop polling the current position and button status, which may easily miss a hit. IMHO, we should give control over to the FE for the actual button hitting (Allowing people to take advantage of native GUI environments), as in: struct BUTTON_INFO { BUTTON_INFO *next; RECT dimmensions; long ID; // Possible data describing what it looks like? } button = FE_GetButtonHit( BUTTON_INFO ); Where it waits for a button hit. This way FE can also handle keyboard overrides etc, for tabbing between buttons. 3) FE_Update takes unsigned long for coordinates. 4) FE_Set: this is a confusing name, I would think FE_GetTicks or something would make more sense? Or FE_GetWhenNextUpdate? 5) I'm against all this needless typedefing. Makes the code difficult to read, especially as both functions and types follow same format (Ie FE_Word). 6) Added FE_Free (req'd if add debugging info to mem. allocation) and changed FE_malloc to FE_Malloc, to remain consistant. 7) GetTicks is REALLY misnamed. GetTicksLeft would be more appropriate. 8) Toggle sound should take some parameters detailing FX, MUSIC, or whatever. Should be left on backburner, though, as we should concentrate on getting it to work :> 9) Why is FE_InitSystem given command line? What's wrong with a config file, and let main parse command line (Command line parsing is not platform specific, is it?) 10) Why is FE_Errornum short? Are we writing it to disk? Do we need it to be precisely 16 bits? If not, isn't `int' better, as it willb e the optimium format for the system in question? 11) As for how do we reset screen after doing a `FE_DisplayScreen', there is a FE_InitScreen for initializing the actuall `play' screen. Probably should be added to UN_PlayGame. 12) Need a special destructor for freeing `pic' data types. Likewise, should add a FE_DestroySprite to destroy stuff created by FE_CompileSprite. 13) Y'know, it would be nice to actually have access to the sine & cosine tables from the front end. Yes, there is sarcasm here. 14) Line 128 of Universe.h has a nested comment. Damn annoying. 15) Doesn't build for me: alife.h includes universe.h which then promptly references AI_Genome_s. Get the error: universe.h(174): Error! E263: (col 1) nested class 'AI_Genome_s' has not been defined Fix: put stub in universe. 16) Serious logic flaw: At or about line 510 of universe.c, there is written something like while( ABS(obj1->x - obj2->x ) > TARGET_DISTANCE ); But, unfortunately, UN_coord is unsigned long, so if obj1->x is less than obj2->x this will always be true. To find distances of unsigned, something like: while( max(obj1->x, obj2->x) - min(obj1->x, obj2->x) > TARGET_DISTANCE ); 17) rand is used in UN_Random, but no #includes are present to bring it in??? With compilers I'm familiar with, #include is req'd. 18) Must do a sweep for FE_malloc -> FE_Malloc and free -> FE_Free. 19) Curiouser and curiouser, when/where is memory actually freed? 20) main.c requirse stdlib.h for `exit' After these changes, it compiles & links fine. Runns and hangs on main menu as no button selection code is enabled. Portability: I've include FEGCC.ASM, which is FEASM with the names & calling convention changed to the C standard (I think :>) Try converting & assembling this. No object files have been included as FEASM is unchanged. - Jeff Lait (SOL) From hpqs0130.sqf.hp.com!smd Thu Nov 30 00:57:00 1995 Return-Path: Received: from hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tL4nO-000fKCC; Thu, 30 Nov 95 00:56 PST Received: from hpqs0123.sqf.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA046001248; Thu, 30 Nov 1995 00:47:30 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA172311247; Thu, 30 Nov 1995 08:47:27 GMT From: Stuart McDonald Message-Id: <199511300847.AA172311247@hpqs0123.sqf.hp.com> Subject: Re: Comments: Please read! To: jmlait@undergrad.math.uwaterloo.ca (Jeff Lait) Date: Thu, 30 Nov 95 8:47:27 GMT Cc: ag-art-sound@krl.caltech.edu, ag-fe@krl.caltech.edu, ag-directors@krl.caltech.edu In-Reply-To: ; from "Jeff Lait" at Nov 29, 95 10:43 pm Mailer: Elm [revision: 70.85] Hi all, Ok, here's some (brief) replies to Jeffs queries.... > 2) FE_PointerStatus: Shouldn't buttons etc, be interrupt based? For example, > to use this one needs a tight loop polling the current position and button > status, which may easily miss a hit. IMHO, we should give control over to > the FE for the actual button hitting (Allowing people to take advantage of > native GUI environments), as in: > > struct BUTTON_INFO { > BUTTON_INFO *next; > RECT dimmensions; > long ID; > // Possible data describing what it looks like? > } > > button = FE_GetButtonHit( BUTTON_INFO ); > > Where it waits for a button hit. This way FE can also handle keyboard > overrides etc, for tabbing between buttons. I agree we need to get rid of the tight loop polling (gobbles up CPU time), I'll have to have a think about how all this will fit into the X version (no time just now). > 4) FE_Set: this is a confusing name, I would think FE_GetTicks or something > would make more sense? Or FE_GetWhenNextUpdate? Well I still aint sure how the ticks system works (I thought I did, but I keep changing my mind 8-). > 5) I'm against all this needless typedefing. Makes the code difficult to > read, especially as both functions and types follow same format (Ie FE_Word). I did ask if anyone had complaints about typedefs, (are you on the Universe group?), regardless they can easilty be removed to renamed to a less confusing format. For myself, I like em, I think the make the code easier to follow, easier to port and less prone to mistakes....but I will happily take them out. > 6) Added FE_Free (req'd if add debugging info to mem. allocation) and changed > FE_malloc to FE_Malloc, to remain consistant. Oops, I had done a search and replace for malloc to add FE_ on the front. > 9) Why is FE_InitSystem given command line? What's wrong with a config file, > and let main parse command line (Command line parsing is not platform > specific, is it?) Yes it is...The X version will need to handle all sorts of specific command line options e.g. -display (Sorry I should have put the comment in the header, not where I called FE_InitSystem) > 10) Why is FE_Errornum short? Are we writing it to disk? Do we need it to > be precisely 16 bits? If not, isn't `int' better, as it willb e the optimium > format for the system in question? I don't like the idea of _anything_ being 'int' (which is of an unknown size) it should be long or short makes no difference. > 11) As for how do we reset screen after doing a `FE_DisplayScreen', there is > a FE_InitScreen for initializing the actuall `play' screen. Probably should > be added to UN_PlayGame. Not sure I follow this one... > 13) Y'know, it would be nice to actually have access to the sine & cosine > tables from the front end. Yes, there is sarcasm here. Sorry, I moved everything I thought was local to inside the .c file. (The above is why I did it, so you can tell what is part of the outside interface and what isn't. So now I know the sin&cos are part of the interface 8-) > 14) Line 128 of Universe.h has a nested comment. Damn annoying. Oops. Sorry. > 15) Doesn't build for me: alife.h includes universe.h which then promptly > references AI_Genome_s. Get the error: > universe.h(174): Error! E263: (col 1) nested class 'AI_Genome_s' has not been > defined > Fix: put stub in universe. Damn, thought I'd got all that stuff. (I hate compilers that let you get away with things like that). > 16) Serious logic flaw: At or about line 510 of universe.c, there is written > something like > while( ABS(obj1->x - obj2->x ) > TARGET_DISTANCE ); > But, unfortunately, UN_coord is unsigned long, so if obj1->x is less than > obj2->x this will always be true. To find distances of unsigned, something > like: > while( max(obj1->x, obj2->x) - min(obj1->x, obj2->x) > TARGET_DISTANCE ); > I was wondering about this coz I had the same bug recently, but I got sidetracked by the ABS (which I stupidly thought made it ok, duh). How about the following hack.... #define SUBXY(x,y) ((x) > (y) ? ((x)-(y)) : ((y)-(x))) e.g. while( SUBXY(obj1->x,obj2->y) > TARGET_DISTANCE ) > 17) rand is used in UN_Random, but no #includes are present to bring it in?? > With compilers I'm familiar with, #include is req'd. Arragh, I'll say it again...I HATE LAZY COMPILERS (they prompt lazy programming 8-) > 19) Curiouser and curiouser, when/where is memory actually freed? No where at the moment 8-) > 20) main.c requirse stdlib.h for `exit' Hmmm I had added that one at some point... > After these changes, it compiles & links fine. Runns and hangs on main > menu as no button selection code is enabled. > > - Jeff Lait (SOL) We'll get there yet 8-) Cheers, Stuart. -- Stuart McDonald :: HP - TSD SQF Scotland :: smd@hpsqf.sqf.hp.com 10 INPUT A " Aaah, the good old 20 INPUT B: POKE A,B: LET A = A + 1: GOTO 20 days..." From charles Thu Nov 30 09:32:26 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLCqN-000fJnC; Thu, 30 Nov 95 09:32 PST Received: by altair.krl.caltech.edu; (5.65v3.0/1.1.8.2/14Apr95-0417PM) id AA28585; Thu, 30 Nov 1995 09:27:51 -0800 Message-Id: <9511301727.AA28585@altair.krl.caltech.edu> Subject: P:VN Administration notes.... To: ag-directors Date: Thu, 30 Nov 1995 09:27:50 -0800 (PST) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2445 Greetings folks, So as some of you may have noticed, I've been being quite quiet for the past few months - I must appologize for this, but unfortunately I don't see it ending any time soon. I have been keeping up with everything, and reading all of the e-mail, and I will certainly reply if I have anything of drastic importance to say. What I haven't been doing is actually going through code, which has left me out of much of what's going on. Due to this, and Badcoe's wonderful work in the group, I've passed my co-ordinator title over to him. It doesn't mean all that much, I realize, but he does deserve it more than I at the moment. I've moved myself over to just "Information Coordinator" which I think I'll be able to do a lot more with the little time I have to devote to the project. I really want to get the web pages in good shape, and keep a nice outline of exactly where we are in the project. Other bits and pieces... 1) I was thinking of adding Toby to the director's list. He's been doing some great work in the ag-alife group from what I can tell. Any objections? 2) I've updated the web pages a little bit (by adding on Stuart and Badcoe's names and positions) and want to do a number of overhauls. What I'm thinking might be appropriate here is adding on a new mailing list (something to the effect of ag-info) to hadle all of the information control. 3) I'd like each of the groups (perhaps working with the ag-info group) to maintain three "lists". One of things completed by that group; a second of things currently being done, or to be done in the near future; and a final one of things which still need to be done before the game is releaseable. This will be especially good for new people to get a good idea of exactly where we are in the project. 4) What are our plan's on advertising? I think a number of the groups are making real progress at the moment, so that is good reason to hold off on it. Also, it doesn't look like I'm going to be moving over to any kind of automated list-server any time soon. I guess this isn't too big of a deal - it doesn't take me a long time to update the list; my only problem is that people ask a *lot* of questions when they join, and I like to at least try to answer them all. Does anyone have an idea on how we might better distribute this task? :-) I think that's about it for now... --- Charles From undergrad.math.uwaterloo.ca!jmlait Thu Nov 30 18:46:46 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLLUD-000fKjC; Thu, 30 Nov 95 18:46 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id VAA07000; Thu, 30 Nov 1995 21:37:53 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id VAA11984; Thu, 30 Nov 1995 21:37:50 -0500 Date: Thu, 30 Nov 1995 21:37:49 -0500 (EST) From: Jeff Lait cc: ag-art-sound@krl.caltech.edu, ag-fe@krl.caltech.edu, ag-directors@krl.caltech.edu Subject: Re: Comments: Please read! In-Reply-To: <199511300847.AA172311247@hpqs0123.sqf.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 30 Nov 1995, Stuart McDonald wrote: > > 5) I'm against all this needless typedefing. Makes the code difficult to > > read, especially as both functions and types follow same format (Ie FE_Word). > > I did ask if anyone had complaints about typedefs, (are you on the Universe > group?), regardless they can easilty be removed to renamed to a less > confusing format. For myself, I like em, I think the make the code easier to > follow, easier to port and less prone to mistakes....but I will happily take > them out. No, I'm not on the universe list. Nor should I. Anyways, how would this be: make all types ALL-CAPS. This way they are easily distinguishable from functions (and are easier to type) > > 9) Why is FE_InitSystem given command line? What's wrong with a config file, > > and let main parse command line (Command line parsing is not platform > > specific, is it?) > > Yes it is...The X version will need to handle all sorts of specific command > line options e.g. -display (Sorry I should have put the comment in the > header, not where I called FE_InitSystem) I disagree. Any such system specific thing should probably be in the config file. PC-X too may require a display (VGA/SVGA/ blah) style modifier, but I don't se why the user needs to type in all his config info every time. Is there some reason under X that you must have a command line and a config file own't do? > > 10) Why is FE_Errornum short? Are we writing it to disk? Do we need it to > > be precisely 16 bits? If not, isn't `int' better, as it willb e the optimium > > format for the system in question? > > I don't like the idea of _anything_ being 'int' (which is of an unknown size) > it should be long or short makes no difference. > Actually it does. Shorts are slower than hell on the 80x86 platform (Specially so with the new p6, or so I hear). My understanding of `int' is that it is selected by the compiler to be the best native format. I have a suggestion for a solution to this disagreement, though. We creare another header file which defines all the basic types for a system. For example: typedef INT int; typedef UINT unsigned int; typedef INT32 long; typedef INT16 short; etc. Where INT, for example is a signed number of indeterminate size (But a minimum of 16nits, say) which should be used wherever scratch variables are required. This header could be redefined for each platform to take advatage of whateer format they like best. Also, the use of `UINT' severely reduces line lengths and clears up code (unsigned int or whatever is way too long) (If you wonder why I'm sddenly supporting typedefs, note that these are `general' typedefs. I'm against the FE_TICKS of the world ...) > > 11) As for how do we reset screen after doing a `FE_DisplayScreen', there is > > a FE_InitScreen for initializing the actuall `play' screen. Probably should > > be added to UN_PlayGame. > > Not sure I follow this one... Before you start doing FE_Update's we probably need to be told that you are finished with thtat menu you had created/loaded. > > 15) Doesn't build for me: alife.h includes universe.h which then promptly > > references AI_Genome_s. Get the error: > > universe.h(174): Error! E263: (col 1) nested class 'AI_Genome_s' has not been > > defined > > Fix: put stub in universe. > > Damn, thought I'd got all that stuff. (I hate compilers that let you get away > with things like that). > Agreed. Some leniancy is good, but can lead to roblems when others attempt to use it. > > 16) Serious logic flaw: At or about line 510 of universe.c, there is written > > something like > > while( ABS(obj1->x - obj2->x ) > TARGET_DISTANCE ); > > But, unfortunately, UN_coord is unsigned long, so if obj1->x is less than > > obj2->x this will always be true. To find distances of unsigned, something > > like: > > while( max(obj1->x, obj2->x) - min(obj1->x, obj2->x) > TARGET_DISTANCE ); > > > > I was wondering about this coz I had the same bug recently, but I got > sidetracked by the ABS (which I stupidly thought made it ok, duh). How about > the following hack.... > > #define SUBXY(x,y) ((x) > (y) ? ((x)-(y)) : ((y)-(x))) > > e.g. > > while( SUBXY(obj1->x,obj2->y) > TARGET_DISTANCE ) > Yes, that would cut out the extra comparison of my naive max/min method. > > 20) main.c requirse stdlib.h for `exit' > > Hmmm I had added that one at some point... > It is possible I lost it myself when deleteing mesage headers. > > After these changes, it compiles & links fine. Runns and hangs on main > > menu as no button selection code is enabled. > > > > - Jeff Lait (SOL) > > > We'll get there yet 8-) > When you determine how the button api will work, I'll throw in a mouse handler and see if we can get the menus working. - Jeff Lait (SOL) From hpqs0130.sqf.hp.com!smd Thu Nov 30 23:33:05 1995 Return-Path: Received: from relay.hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLPxO-000fKwC; Thu, 30 Nov 95 23:32 PST Received: from hpqs0123.sqf.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA036952654; Thu, 30 Nov 1995 23:24:15 -0800 Received: by hpqs0123.sqf.hp.com (1.37.109.16/15.5+ECS 3.4 ) id AA179902653; Fri, 1 Dec 1995 07:24:13 GMT From: Stuart McDonald Message-Id: <199512010724.AA179902653@hpqs0123.sqf.hp.com> Subject: Re: Comments: Please read! To: jmlait@undergrad.math.uwaterloo.ca (Jeff Lait) Date: Fri, 1 Dec 95 7:24:12 GMT Cc: ag-art-sound@krl.caltech.edu, ag-fe@krl.caltech.edu, ag-directors@krl.caltech.edu In-Reply-To: ; from "Jeff Lait" at Nov 30, 95 9:37 pm Mailer: Elm [revision: 70.85] Hi All, > On Thu, 30 Nov 1995, Stuart McDonald wrote: > >>> 5) I'm against all this needless typedefing. Makes the code difficult to >>> read, especially as both functions and types follow same format (Ie >>> FE_Word). >> >> I did ask if anyone had complaints about typedefs, (are you on the Universe >> group?), regardless they can easilty be removed to renamed to a less >> confusing format. For myself, I like em, I think the make the code easier >> to follow, easier to port and less prone to mistakes....but I will happily >> take them out. > > No, I'm not on the universe list. Nor should I. Anyways, how > would this be: make all types ALL-CAPS. This way they are easily > distinguishable from functions (and are easier to type) > Fine by me, how about a vote. 1) All Caps typedefs 2) Remove 3) Some other. >>> 9) Why is FE_InitSystem given command line? What's wrong with a config >>> file, and let main parse command line (Command line parsing is not platform >>> specific, is it?) >> >> Yes it is...The X version will need to handle all sorts of specific command >> line options e.g. -display (Sorry I should have put the comment in the >> header, not where I called FE_InitSystem) > > I disagree. Any such system specific thing should probably be in > the config file. PC-X too may require a display (VGA/SVGA/ blah) style > modifier, but I don't se why the user needs to type in all his config > info every time. > Is there some reason under X that you must have a command line > and a config file own't do? Yes. X programs should _all_ take certain command line options. These options can also be given in a config file, but things like -display _must_ be possible from the command line (well it will work if you can't but it will go against every other X program ). > >>> 10) Why is FE_Errornum short? Are we writing it to disk? Do we need it to >>> be precisely 16 bits? If not, isn't `int' better, as it willb e the >>> optimium format for the system in question? >> >> I don't like the idea of _anything_ being 'int' (which is of an unknown >> size) it should be long or short makes no difference. >> > Actually it does. Shorts are slower than hell on the 80x86 > platform (Specially so with the new p6, or so I hear). My understanding > of `int' is that it is selected by the compiler to be the best native format. Something I meant to ask, I aint done any real-move x86 programming is 32*32bit multiply with 64 bit result faster on a 486? than 16*16? Coz folk in the UN group told me that FE want all longs because its faster and that surprized me. (It's also a reason why I wanted typedefs, coz it may not be the best on all systems). > I have a suggestion for a solution to this disagreement, though. > We creare another header file which defines all the basic types for a > system. For example: > typedef INT int; > typedef UINT unsigned int; > typedef INT32 long; > typedef INT16 short; > etc. Where INT, for example is a signed number of indeterminate size > (But a minimum of 16nits, say) which should be used wherever scratch > variables are required. This header could be redefined for each platform > to take advatage of whateer format they like best. Also, the use of > `UINT' severely reduces line lengths and clears up code (unsigned int or > whatever is way too long) > (If you wonder why I'm sddenly supporting typedefs, note that > these are `general' typedefs. I'm against the FE_TICKS of the world ...) No objections here (we use the same system for the stuff I'm doing back in the Real World (tm)) > >>> 11) As for how do we reset screen after doing a `FE_DisplayScreen', there is >>> a FE_InitScreen for initializing the actuall `play' screen. Probably should >>> be added to UN_PlayGame. >> >> Not sure I follow this one... > Before you start doing FE_Update's we probably need to be told > that you are finished with thtat menu you had created/loaded. > Oh yeah got you. Yes there should be. >> We'll get there yet 8-) >> > When you determine how the button api will work, I'll throw in a > mouse handler and see if we can get the menus working. > > - Jeff Lait (SOL) I have a problem with doing any coding right now....My computer blew up (or rather it did the ominous Silent Black Screen on me). I've been threatening to replace/upgrade for a while (I _need_ Linnux, DOS/Windows just drives me insane). So if Adrian/Martijn/whoever could take over making changes to the UN code (not that I had control). I will try and get ideas etc done here at work, but time is scarce right now (started at 6:30) and hopefully I'll have a working PC for over the Christmas break and we can farm out different bits of the code to people to work on (what do you mean it's a holiday 8-). Cheers, Stuart. From dl.ac.uk!mbbad Fri Dec 1 01:30:34 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLRkA-000fKuC; Fri, 1 Dec 95 01:26 PST Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with ESMTP id JAA08189 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Fri, 1 Dec 1995 09:18:53 GMT Precedence: first-class Received: by s-crim1.dl.ac.uk (950911.SGI.8.6.12.PATCH825/930817.MJE) id JAA29028; Fri, 1 Dec 1995 09:18:32 GMT Date: Fri, 1 Dec 1995 09:18:32 +0000 (GMT) From: "I. Badcoe" Subject: Re: P:VN Administration notes.... To: Splinterwood cc: ag-directors@krl.caltech.edu In-Reply-To: <9511301727.AA28585@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 30 Nov 1995, Splinterwood wrote: > 1) I was thinking of adding Toby to the director's list. He's been doing > some great work in the ag-alife group from what I can tell. Any > objections? Sure. > 3) I'd like each of the groups (perhaps working with the ag-info group) to > maintain three "lists". One of things completed by that group; a second > of things currently being done, or to be done in the near future; and a > final one of things which still need to be done before the game is > releaseable. This will be especially good for new people to get a good > idea of exactly where we are in the project. Maintain how, just mail you new versions ? > 4) What are our plan's on advertising? I think a number of the groups are > making real progress at the moment, so that is good reason to hold off on > it. Also, it doesn't look like I'm going to be moving over to any kind > of automated list-server any time soon. I guess this isn't too big of a > deal - it doesn't take me a long time to update the list; my only problem > is that people ask a *lot* of questions when they join, and I like to at > least try to answer them all. Does anyone have an idea on how we might > better distribute this task? :-) Just keep a note of all the questions and answers and stuff them in a FAQ file (perhaps people could help by, when they answer such a question, putting the word FAQ on the subject line). Badders From dl.ac.uk!mbbad Fri Dec 1 01:39:15 1995 Return-Path: Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLRvx-000fKuC; Fri, 1 Dec 95 01:39 PST Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with ESMTP id JAA09036 (8.6.12/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Fri, 1 Dec 1995 09:31:13 GMT Precedence: first-class Received: by s-crim1.dl.ac.uk (950911.SGI.8.6.12.PATCH825/930817.MJE) id JAA00518; Fri, 1 Dec 1995 09:30:51 GMT Date: Fri, 1 Dec 1995 09:30:51 +0000 (GMT) From: "I. Badcoe" Subject: Re: Comments: Please read! cc: ag-art-sound@krl.caltech.edu, ag-fe@krl.caltech.edu, ag-directors@krl.caltech.edu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > No, I'm not on the universe list. Nor should I. Anyways, how > would this be: make all types ALL-CAPS. This way they are easily > distinguishable from functions (and are easier to type) OK, as long as you understand that (for example) AL uses ALL-CAPS for cpp MACROS. My convention has always been to Capitalize things I want to draw attention to (Globals, Arrays, TypeDefs ...) > > > 9) Why is FE_InitSystem given command line? What's wrong with a config file, > > > and let main parse command line (Command line parsing is not platform > > > specific, is it?) > > Yes it is...The X version will need to handle all sorts of specific command > > line options e.g. -display (Sorry I should have put the comment in the > > header, not where I called FE_InitSystem) > I disagree. Any such system specific thing should probably be in > the config file. PC-X too may require a display (VGA/SVGA/ blah) style > modifier, but I don't se why the user needs to type in all his config > info every time. > Is there some reason under X that you must have a command line > and a config file own't do? I might be part of the X interface, certainly a lot of X applications offer very similar command line params. > > > 10) Why is FE_Errornum short? Are we writing it to disk? Do we need it to > > > be precisely 16 bits? If not, isn't `int' better, as it willb e the optimium > > > format for the system in question? > > I don't like the idea of _anything_ being 'int' (which is of an unknown size) > > it should be long or short makes no difference. > Actually it does. Shorts are slower than hell on the 80x86 > platform (Specially so with the new p6, or so I hear). My understanding > of `int' is that it is selected by the compiler to be the best native format. > I have a suggestion for a solution to this disagreement, though. > We creare another header file which defines all the basic types for a > system. For example: > typedef INT int; > typedef UINT unsigned int; > typedef INT32 long; > typedef INT16 short; In AL we already have EINT32 (or it may be E32INT, or INT32E ... but we definitely have it !) #defined to represent the 32-bit data type required by the ALang for its ints. Badders From undergrad.math.uwaterloo.ca!jmlait Fri Dec 1 06:28:07 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLWRS-000fJUC; Fri, 1 Dec 95 06:27 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id JAA20356; Fri, 1 Dec 1995 09:19:44 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id JAA14220; Fri, 1 Dec 1995 09:19:42 -0500 Date: Fri, 1 Dec 1995 09:19:41 -0500 (EST) From: Jeff Lait cc: ag-art-sound@krl.caltech.edu, ag-fe@krl.caltech.edu, ag-directors@krl.caltech.edu Subject: Re: Comments: Please read! In-Reply-To: <199512010724.AA179902653@hpqs0123.sqf.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 1 Dec 1995, Stuart McDonald wrote: > Hi All, > > > On Thu, 30 Nov 1995, Stuart McDonald wrote: > > > > No, I'm not on the universe list. Nor should I. Anyways, how > > would this be: make all types ALL-CAPS. This way they are easily > > distinguishable from functions (and are easier to type) > > > > Fine by me, how about a vote. 1) All Caps typedefs 2) Remove 3) Some other. > I don't like votes. I'd prefer a consensus. I'd be willing to go with all-caps, though internally FE-PCX will be not using as many... > > I disagree. Any such system specific thing should probably be in > > the config file. PC-X too may require a display (VGA/SVGA/ blah) style > > modifier, but I don't se why the user needs to type in all his config > > info every time. > > Is there some reason under X that you must have a command line > > and a config file own't do? > > Yes. X programs should _all_ take certain command line options. These options > can also be given in a config file, but things like -display _must_ be > possible from the command line (well it will work if you can't but it will go > against every other X program ). Hows this: Anything on the command line not understood by the universe code is appended to the config file where the fe-pcx can read it? > > Actually it does. Shorts are slower than hell on the 80x86 > > platform (Specially so with the new p6, or so I hear). My understanding > > of `int' is that it is selected by the compiler to be the best native format. > > Something I meant to ask, I aint done any real-move x86 programming is 32*32bit > multiply with 64 bit result faster on a 486? than 16*16? Coz folk in the UN > group told me that FE want all longs because its faster and that surprized me. > (It's also a reason why I wanted typedefs, coz it may not be the best on all > systems). > Actually, yes. If you're a cycle counter you'll note on the pentium cycle counts for unsigned multiply are 11 for bytes, 11 for words, and 10 for dwords (32bit). This does not count the one cycle hit in proteced mode for interpretting the operand size override prefix (req'd for using 16bit instructions in a 32bit segment. Thus, a 16 bit multiply is 20% slower than a 32 bit. It is even more interesting that a floating point multiply takes 1 cycle, too bad that only started with the pentium :< > > I have a suggestion for a solution to this disagreement, though. > > We creare another header file which defines all the basic types for a > > system. For example: > > typedef INT int; > > typedef UINT unsigned int; > > typedef INT32 long; > > typedef INT16 short; > > (If you wonder why I'm sddenly supporting typedefs, note that > > these are `general' typedefs. I'm against the FE_TICKS of the world ...) > > No objections here (we use the same system for the stuff I'm doing back in the > Real World (tm)) > What a coincidence, so do I. :> - Jeff Lait (SOL) From charles Fri Dec 1 07:46:36 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLXfU-000fJxC; Fri, 1 Dec 95 07:46 PST Received: by altair.krl.caltech.edu; (5.65v3.0/1.1.8.2/14Apr95-0417PM) id AA08446; Fri, 1 Dec 1995 07:41:57 -0800 Message-Id: <9512011541.AA08446@altair.krl.caltech.edu> Subject: Naming schemes... To: ag-fe Date: Fri, 1 Dec 1995 07:41:56 -0800 (PST) From: "Splinterwood" Cc: ag-directors X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 827 Greetings, I noticed that there was a bit of trouble on how exactly to name typdefs... I use some rather non-standard methods typically which I have found to work *very* well. I start the name with a lowercase letter indicating what it is, and then a capital letter for the actual name. For example (I primarily use C++ so I'm going to skip som typedefing): If I were going to have a structure for a creature, I'd call it "sCreature"; If I had an enumerated type for colors, it would be "eColors". A typedef for in int (the case in point) would be "tInt". All told I use 4 initial letters; 's' for struct, 'c' for class, 'e' for enum, and 't' for other typedefs. All #define's are capitalized. All function names *begin* with a capital letter. I've been doing this for years with good results.... --- Charles From undergrad.math.uwaterloo.ca!jmlait Fri Dec 1 16:39:44 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLfz2-000fKlC; Fri, 1 Dec 95 16:39 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id TAA23591; Fri, 1 Dec 1995 19:30:55 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id TAA28773; Fri, 1 Dec 1995 19:30:51 -0500 Date: Fri, 1 Dec 1995 19:30:51 -0500 (EST) From: Jeff Lait cc: ag-fe@krl.caltech.edu, ag-directors@krl.caltech.edu Subject: Re: Naming schemes... In-Reply-To: <9512011541.AA08446@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 1 Dec 1995, Splinterwood wrote: > Greetings, > > I noticed that there was a bit of trouble on how exactly to name > typdefs... I use some rather non-standard methods typically which I have > found to work *very* well. I start the name with a lowercase letter > indicating what it is, and then a capital letter for the actual name. For > example (I primarily use C++ so I'm going to skip som typedefing): Sorry to ruin your day, but it's not THAT nonstandard. cf: Hungarian notation. > If I were going to have a structure for a creature, I'd call it "sCreature"; > If I had an enumerated type for colors, it would be "eColors". A typedef > for in int (the case in point) would be "tInt". All told I use 4 initial > letters; 's' for struct, 'c' for class, 'e' for enum, and 't' for other > typedefs. All #define's are capitalized. All function names *begin* with > a capital letter. I've been doing this for years with good results.... I'd rather go to full blown hungarian (ie: prefix `n' for int, `s; for short, `p' for pointer, `rimg' for RIMAGE, etc) then go half way with prefixes. Just my opinion... - Jeff Lait (SOL) From charles Fri Dec 1 16:44:23 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLg3v-000fKnC; Fri, 1 Dec 95 16:44 PST Received: by altair.krl.caltech.edu; (5.65v3.0/1.1.8.2/14Apr95-0417PM) id AA27961; Fri, 1 Dec 1995 16:39:43 -0800 Message-Id: <9512020039.AA27961@altair.krl.caltech.edu> Subject: Re: Naming schemes... To: jmlait@undergrad.math.uwaterloo.ca (Jeff Lait) Date: Fri, 1 Dec 1995 16:39:43 -0800 (PST) From: "Splinterwood" Cc: ag-fe@krl.caltech.edu, ag-directors@krl.caltech.edu In-Reply-To: from "Jeff Lait" at Dec 1, 95 07:30:51 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 390 > Sorry to ruin your day, but it's not THAT nonstandard. cf: > Hungarian notation. Not ruining... Nice to know what there is to it actually . :-) I'll have to look it up. > I'd rather go to full blown hungarian (ie: prefix `n' for int, > `s; for short, `p' for pointer, `rimg' for RIMAGE, etc) then go half way > with prefixes. Just my opinion... Sounds good. --- Charles From undergrad.math.uwaterloo.ca!jmlait Sat Dec 2 04:25:39 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLWfd-000fJjC; Fri, 1 Dec 95 06:42 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id JAA23151; Fri, 1 Dec 1995 09:34:17 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id JAA15849; Fri, 1 Dec 1995 09:34:14 -0500 Date: Fri, 1 Dec 1995 09:34:13 -0500 (EST) From: Jeff Lait To: "I. Badcoe" cc: ag-art-sound@krl.caltech.edu, ag-fe@krl.caltech.edu, ag-directors@krl.caltech.edu Subject: Re: Comments: Please read! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 1 Dec 1995, I. Badcoe wrote: > > No, I'm not on the universe list. Nor should I. Anyways, how > > would this be: make all types ALL-CAPS. This way they are easily > > distinguishable from functions (and are easier to type) > > OK, as long as you understand that (for example) AL uses ALL-CAPS for cpp > MACROS. > > My convention has always been to Capitalize things I want to draw > attention to (Globals, Arrays, TypeDefs ...) > Trouble here though is that both functions and types have the exact same capitalization & prefix standard. Thus one gets: FE_Ticks FE_GetTicks(...) which is difficult to scan. Compare & contrast to: FE_TICKS FE_GetTicks(...) where it is easy to seperate return type from function. > In AL we already have EINT32 (or it may be E32INT, or INT32E ... but we > definitely have it !) #defined to represent the 32-bit data type required > by the ALang for its ints. Seems we all agree that such a standard wiykd be a Good Thing, so now we just need to determine what to call it... - Jeff Lait (SOL) From dunx1.ocs.drexel.edu!st944m5h Sat Dec 2 08:04:06 1995 Return-Path: Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tLuPa-000fIzC; Sat, 2 Dec 95 08:03 PST Received: from [144.118.247.250] (newtower1-005.resnet.drexel.edu [144.118.247.250]) by dunx1.ocs.drexel.edu (8.6.12/8.6.12) with SMTP id KAA22035 for ; Sat, 2 Dec 1995 10:53:34 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 2 Dec 1995 10:57:56 -0400 To: ag-directors@krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Command Line options. >Is this discussion worth the bother? I agree that eventually need a config >file. Universe can probably handle most of this (the main front end specific >thing here is length of filename restrictions). As for the command line >options; if a front end needs this, then why doesn't that person doing >the front end code for that adapt this code so it is able to use command >line options? > >I suppose I end up saying the same thing as Jeff here. Using a config file, >and some front ends can override(add?) options in it by using command line >options. > >Martijn I agree with this, especially because Mac's have no CLI... :-) (posted to directors because the actual conversation seems to be across several lists) -- Michael Mitchener st944m5h@dunx1.ocs.drexel.edu From charles Sat Dec 2 16:39:52 1995 Return-Path: Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tM2T7-000fJcC; Sat, 2 Dec 95 16:39 PST Received: by altair.krl.caltech.edu; (5.65v3.0/1.1.8.2/14Apr95-0417PM) id AA18349; Sat, 2 Dec 1995 16:35:10 -0800 Message-Id: <9512030035.AA18349@altair.krl.caltech.edu> Subject: Toby is added... To: ag-directors Date: Sat, 2 Dec 1995 16:35:09 -0800 (PST) From: "Splinterwood" X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 90 ...to the directors list. Welcome! (and thanx for all the great work!) --- Charles From phil.ruu.nl!faassen Fri Dec 22 02:50:14 1995 Return-Path: Received: from moe.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tT506-000fKsC; Fri, 22 Dec 95 02:46 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by moe.phil.ruu.nl (8.7.1/8.6.12) with ESMTP id LAA01947; Fri, 22 Dec 1995 11:41:31 +0100 (MET) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.7.1/8.6.12) id LAA02084; Fri, 22 Dec 1995 11:41:29 +0100 (MET) From: Martijn Faassen Message-Id: <199512221041.LAA02084@laurel.stud.phil.ruu.nl> Subject: Happy holidays! To: ag-universe@alnilam.krl.caltech.edu (ag universe), ag-alife@alnilam.krl.caltech.edu (ag alife), ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Fri, 22 Dec 1995 11:41:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi everybody, I won't be on the net until the first week of january, so happy holidays to you all! I'll do much thinking on PVN during the holidays, of course. In january I plan to start kicking this project forward again quite a bit. So, I'm giving it a fair warning. It should buy armor. Happy holidays! Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From undergrad.math.uwaterloo.ca!jmlait Fri Dec 22 10:20:31 1995 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0tTC1z-000fKyC; Fri, 22 Dec 95 10:17 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.6.12/8.6.12UW) with ESMTP id NAA14984; Fri, 22 Dec 1995 13:11:56 -0500 Received: (jmlait@localhost) by cayley.uwaterloo.ca (8.6.12/8.6.12UW) id NAA21082; Fri, 22 Dec 1995 13:11:55 -0500 Date: Fri, 22 Dec 1995 13:11:55 -0500 (EST) From: Jeff Lait To: Martijn Faassen cc: ag universe , ag alife , AG Directors Subject: Re: Happy holidays! In-Reply-To: <199512221041.LAA02084@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 22 Dec 1995, Martijn Faassen wrote: > > Hi everybody, > > I won't be on the net until the first week of january, so happy > holidays to you all! I'll do much thinking on PVN during the holidays, > of course. In january I plan to start kicking this project forward again > quite a bit. So, I'm giving it a fair warning. It should buy armor. That's the spirit. I'm on school term so should have time to devote as well to this project.... Though didn't I say that when I went on work term I'd have more time? Who says you have to be consistant. - Jeff Lait (SOL) From compuserve.com!Adrian_Tymes Tue Mar 18 19:46:32 1997 Return-Path: Received: from arl-img-7.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0w7CKK-000fIrC; Tue, 18 Mar 97 19:46 PST Received: by arl-img-7.compuserve.com (8.6.10/5.950515) id WAA05387; Tue, 18 Mar 1997 22:35:55 -0500 Date: Tue, 18 Mar 1997 22:35:41 -0500 From: Adrian Tymes Subject: Help! To: AG-Directors Message-ID: <199703182235_MC2-12CC-F652@compuserve.com> It has been over a month and a half since there has been any traffic on the ag-universe list, and I am completely out of ideas as to how to encourage participation. Our code is serviceable, but not complete. I can not finish the group's work by myself. Does anyone know how I can recruit programmers, or even people willing to test what we have so far? From charles Wed Mar 19 10:32:33 1997 Return-Path: Received: from regulus.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0w7Q9r-000fIrC; Wed, 19 Mar 97 10:32 PST Received: by regulus.krl.caltech.edu; (5.65v3.0/1.1.8.2/07Apr95-0112PM) id AA31027; Wed, 19 Mar 1997 10:23:10 -0800 From: Message-Id: <9703191823.AA31027@regulus.krl.caltech.edu> Subject: Re: Help! To: Adrian_Tymes@compuserve.com (Adrian Tymes) Date: Wed, 19 Mar 1997 10:23:09 -0800 (PST) Cc: ag-directors In-Reply-To: <199703182235_MC2-12CC-F652@compuserve.com> from "Adrian Tymes" at Mar 18, 97 10:35:41 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1178 > It has been over a month and a half since there has been any traffic on the > ag-universe list, and I am completely out of ideas as to how to encourage > participation. Our code is serviceable, but not complete. I can not > finish the group's work by myself. Does anyone know how I can recruit > programmers, or even people willing to test what we have so far? I agree that we're having a huge problem here. The main drawback from advertising and getting an influx of people is that I have to maintain all of the mailing lists by hand, and keep falling behind on it. Plus I'm not allowed to maintain 'large' mailing lists on this system, which I'm sure this would become if we advertised. Without going public, we already have about 70 people on the lists! People are still asking to be added all the time. I tell them the project is in a major lull, and then add them. So, what I'm asking now is if anyone knows where we could put the mailing lists such that they would be automated. I've looked, and haven't had any luck. I don't mind keeping the web pages up-to-date as I have time, but the mailing lists are a real pain. Any suggestions? --- Charles From tcp.co.uk!htrd Thu Mar 20 03:38:58 1997 Return-Path: Received: from zeus.tcp.net.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0w7gB5-000fIrC; Thu, 20 Mar 97 03:38 PST Received: from ai036.du.pipex.com (ai036.du.pipex.com [193.130.248.36]) by zeus.tcp.net.uk (8.7.6/8.7) with SMTP id LAA24889 for ; Thu, 20 Mar 1997 11:28:13 GMT From: htrd@tcp.co.uk (Toby Dickenson) To: ag-directors@krl.caltech.edu Subject: Re: Help! Date: Thu, 20 Mar 1997 19:30:04 GMT Message-ID: <33318b24.592337890@mail.tcp.co.uk> References: <9703191823.AA31027@regulus.krl.caltech.edu> In-Reply-To: <9703191823.AA31027@regulus.krl.caltech.edu> X-Mailer: Forte Agent .99g/32.339 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Wed, 19 Mar 1997 10:23:09 -0800 (PST), you wrote: >> It has been over a month and a half since there has been any traffic on the >> ag-universe list, and I am completely out of ideas as to how to encourage >> participation. Our code is serviceable, but not complete. I can not >> finish the group's work by myself. Does anyone know how I can recruit >> programmers, or even people willing to test what we have so far? ag-alife has been idle to.... for so long that I had forgotten I was still subscribed. At one point both lists were quite busy. Do we know where people have gone, and why the traffic has died down? Speaking personally, my contributions stopped because I felt the project as it had developed would not succeed in its main goals. Not through lack of development effort, but for technical reasons. I am still interested in the ideal behind the project, which is why I originally sayed on the list, but don't feel I can offer development effort so something in which I see little chance of success. Perhaps other contributors feel similarly? Perhaps this would be the time to let the project die? >I agree that we're having a huge problem here. The main drawback from >advertising and getting an influx of people is that I have to maintain all >of the mailing lists by hand, and keep falling behind on it. Plus I'm not >allowed to maintain 'large' mailing lists on this system, which I'm sure >this would become if we advertised. Without going public, we already have >about 70 people on the lists! People are still asking to be added all the >time. I tell them the project is in a major lull, and then add them. > >So, what I'm asking now is if anyone knows where we could put the mailing >lists such that they would be automated. I've looked, and haven't had any >luck. I don't mind keeping the web pages up-to-date as I have time, but >the mailing lists are a real pain. > >Any suggestions? > > --- Charles > Sorry for the negative news ;-( ------------------------------------------------------------------------------ Toby Dickenson PGP Key ID: 63CCA0A1 htrd@tcp.co.uk Fingerprint: 45 B4 8A 79 67 03 1B 11 37 29 F5 5C B5 FD 2C A2 ------------------------------------------------------------------------------ From cayley.uwaterloo.ca!jmlait Thu Mar 20 13:36:17 1997 Return-Path: Received: from cayley.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0w7pVL-000fJqC; Thu, 20 Mar 97 13:36 PST Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id QAA02655 for ; Thu, 20 Mar 1997 16:25:45 -0500 (EST) Date: Thu, 20 Mar 1997 16:25:43 -0500 (EST) From: Jeff Lait cc: ag-directors@krl.caltech.edu Subject: Re: Help! In-Reply-To: <33318b24.592337890@mail.tcp.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 20 Mar 1997, Toby Dickenson wrote: > On Wed, 19 Mar 1997 10:23:09 -0800 (PST), you wrote: > > >> It has been over a month and a half since there has been any traffic on the > >> ag-universe list, and I am completely out of ideas as to how to encourage > >> participation. Our code is serviceable, but not complete. I can not > >> finish the group's work by myself. Does anyone know how I can recruit > >> programmers, or even people willing to test what we have so far? > > ag-alife has been idle to.... for so long that I had forgotten I was still > subscribed. > Ditto for the front-end groups. (PCX, etc) > At one point both lists were quite busy. Do we know where people have gone, and > why the traffic has died down? > > Speaking personally, my contributions stopped because I felt the project as it > had developed would not succeed in its main goals. Not through lack of > development effort, but for technical reasons. I am still interested in the > ideal behind the project, which is why I originally sayed on the list, but don't > feel I can offer development effort so something in which I see little chance of > success. > That is the question: where does alife stand? This entire project requires the alife component to be worthwhile, to not be yet another asteroids. > Perhaps other contributors feel similarly? Perhaps this would be the time to let > the project die? I'd say that's up to the a-life team. If that group has given up/determined it is impractical (So long as CPU power isn't the concern: CPU ower has tripled since we started this project...) > > >I agree that we're having a huge problem here. The main drawback from > >advertising and getting an influx of people is that I have to maintain all > >of the mailing lists by hand, and keep falling behind on it. Plus I'm not > >allowed to maintain 'large' mailing lists on this system, which I'm sure > >this would become if we advertised. Without going public, we already have > >about 70 people on the lists! People are still asking to be added all the > >time. I tell them the project is in a major lull, and then add them. > > And where are these eeople? Every so often I get someone who is interested in the project, so I assign them a task & send them code and never hear from them again. > >So, what I'm asking now is if anyone knows where we could put the mailing > >lists such that they would be automated. I've looked, and haven't had any > >luck. I don't mind keeping the web pages up-to-date as I have time, but > >the mailing lists are a real pain. > > Sorry for the negative news ;-( > Wish I could be more positive myself. I tend to lack both the time & motivation, the latter due to an absense of progress on the alife end. I'll commit this much, though. If the alife team produces a system which requires a frontend, that front-end will be made. Until then, I've got this on the back burner.A - Jeff Lait (SOL) From phil.ruu.nl!Martijn.Faassen Thu Mar 20 13:57:12 1997 Return-Path: Received: from moe.serv.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0w7ppX-000fJeC; Thu, 20 Mar 97 13:57 PST Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.141.23]) by moe.serv.phil.ruu.nl (8.8.5/8.8.5/KKm1.6) with ESMTP id WAA09505 for ; Thu, 20 Mar 1997 22:46:38 +0100 (MET) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.8.5/8.8.5/KKs1.6) id WAA12343 for ag-directors@alnilam.krl.caltech.edu; Thu, 20 Mar 1997 22:46:36 +0100 (MET) From: Martijn Faassen Message-Id: <199703202146.WAA12343@laurel.stud.phil.ruu.nl> Subject: Re: Help! To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 20 Mar 1997 22:46:36 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi everybody, I myself am currently rather too busy with 2 or 3 other things to look a lot at PvN. In a couple of weeks some of that pressure may be gone, which might enable me to look at the stuff again. On the Alife group: Badcoe was the one who (together with Toby, I think?) coded up the alife engine. There's actually a large part of it there, waiting to be extended, modified. I haven't delved into it yet. As an alternative, it wouldn't be so hard for me (or Charles for that matter) to hack up a virtual machine language alife engine as well (instead of the genetic programming style engine we have now). I and Charles both have experience in implementing such systems, and executing virtual machine code tends to be a lot easier than executing a GP tree. Most of the times groups tend to be more alive when there are driving forces around to keep the action going. Badcoe used to be a great driving force, but when he got another job he disappeared off the list, not to return. (or is he there?) I used to be more of a driving force than I am now, as well, but real life interferes rather gravely. I haven't *forgotten* about PvN though..I just don't have time. But I will..Eventually. What also might help is some organisation & promotion of the ftp site. For me personally it's rather a pain to save code from email and then pack them and take them on a floppy home. A nice tarred and/or zipped ftp file would be much easier to deal with. In general, some organisation talent is needed. Perhaps we could advertise for an organisation talent on the net somewhere. Then the directors can review the applications and we'll pick the best of 'm. :) It's an actual possibility. I'd be willing to write & post such an ad for a 'director', if I get sufficient input from you all about what we want, and if we can determine the newsgroups where we want to post the ad. A final note: Toby may be right about the difficulties with getting sufficient evolution within the game time. Note though that the gaming universe is potentially *vast*; witness for example what happens with the commercial game 'Creatures'. People exchange creatures through the 'net, and such. This could be happen with probes as well. (and we could of course make the software automatically 'email' probes to other running instances, if we could figure out how :). Also, we don't know until we try. I haven't given up hope yet. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From compuserve.com!Adrian_Tymes Mon Mar 24 19:30:08 1997 Return-Path: Received: from arl-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0w9Mvd-000fIrC; Mon, 24 Mar 97 19:29 PST Received: by arl-img-4.compuserve.com (8.6.10/5.950515) id WAA09693; Mon, 24 Mar 1997 22:19:00 -0500 Date: Mon, 24 Mar 1997 22:18:36 -0500 From: Adrian Tymes Subject: Re: Help! To: AG-Directors Message-ID: <199703242218_MC2-1336-BA17@compuserve.com> >> ag-alife has been idle to.... for so long that I had forgotten I was still >> subscribed. >> > Ditto for the front-end groups. (PCX, etc) When I sent the letter, I was afraid that my group was holding everything back by its lack of progress. I'm not sure whether to be relieved or saddened that that's not the case. >> At one point both lists were quite busy. Do we know where people have gone, and >> why the traffic has died down? I can only speak for the universe list, but the main problem there was a rash of people who volunteered to write code, and then just dissapeared. I could never tell in advance who was going to flake, and when follow-up checks via direct e-mail to the missing coders produced no response, everyone had to wait while the new sections were integrated and we reassessed what was still missing. This bled enthusiasm from the group, until the last round of integrate-and-review (circa New Year's) produced no responses. After a month of silence on the list (in hindsight, probably too long of a wait), I tried to rekindle the discussion, but to no avail. My next e-mail on the project was the start of this thread. That is a partial answer to your second question. As for your first, all I can say is that the missing people aren't answering even direct e-mail, but e-mail to their accounts is not bouncing. My best guess is that they have abandoned the e-mail accounts that they were using when they volunteered, but no one has bothered to remove them. > I'd say that's up to the a-life team. If that group has given >up/determined it is impractical (So long as CPU power isn't the concern: >CPU ower has tripled since we started this project...) The universe had stub functions for both AI and FE functions. Even if neither group had gotten anywhere (which I'm glad to hear is not the case), it would not have affected us until it came time to replace these stub functions with the actual AI and FE code. > And where are these eeople? Every so often I get someone who is >interested in the project, so I assign them a task & send them code and >never hear from them again. What can I say? Amen. :) >> >So, what I'm asking now is if anyone knows where we could put the mailing >> >lists such that they would be automated. I've looked, and haven't had any >> >luck. I don't mind keeping the web pages up-to-date as I have time, but >> >the mailing lists are a real pain. I have partial control of a few more resources now than I did a few years ago. (For instance, a good portion of a class C namespace, a significant Windows/Macintosh network, etc.) Unfortunately, these are the property of a corporate entity. I will try to see if I can convince them to let me run a listserv program from this network, but don't keep your fingers crossed... they already know about P:VN, and their net's resources are already stretched thin from buisiness uses. It would help if someone could point me at a low-maintenance, cheap (or free), reliable (ie: it *will not* crash the system it is run on) listserv program for Windows NT. The basic research I've done so far has not shown me any suitable prospects. > I'll commit this much, though. If the alife team produces a >system which requires a frontend, that front-end will be made. If I could get even one person to help with the universe code, that effort would still be going. However, I do not have enough time to create the whole universe by myself. From darkin.demon.co.uk!christian Thu Mar 27 04:38:49 1997 Return-Path: Received: from relay-11.mail.demon.net by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wAERj-000fJeC; Thu, 27 Mar 97 04:38 PST Received: from darkin.demon.co.uk ([158.152.65.117]) by relay-11.mail.demon.net id aa1122517; 27 Mar 97 12:21 GMT Date: Thu, 27 Mar 1997 09:15:11 GMT From: Christian Darkin Reply-To: christian@darkin.demon.co.uk Message-Id: <4@darkin.demon.co.uk> To: Adrian_Tymes@compuserve.com, charles@krl.caltech.edu Cc: ag-directors@krl.caltech.edu Subject: Re: Re: Help! X-Mailer: FIMail V0.9d X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS Lines: 38 In your message dated Wednesday 19, March 1997 you wrote : > I agree that we're having a huge problem here. The main drawback from > advertising and getting an influx of people is that I have to maintain all > of the mailing lists by hand, and keep falling behind on it. Plus I'm not > allowed to maintain 'large' mailing lists on this system, which I'm sure > this would become if we advertised. Without going public, we already have > about 70 people on the lists! People are still asking to be added all the > time. I tell them the project is in a major lull, and then add them. > > So, what I'm asking now is if anyone knows where we could put the mailing > lists such that they would be automated. I've looked, and haven't had any > luck. I don't mind keeping the web pages up-to-date as I have time, but > the mailing lists are a real pain. > Any suggestions? I suppose we could do a kind of "archive" - that is find out who out of these 70 people wants to get actively talking again, and can add something useful to what we're doing - and then keep the rest as just email adresses who we can send a regular digest to. That way, we could make way for a smaller group of focussed, active individuals. How does that sound? > > --- Charles > > > -- --------------------------------------------------------------------------- | Christian Darkin EMail christian@ | | Mail sent via Demon Internet - Full IP for 10/Month Tel:0181 371 1234 | --------------------------------------------------------------------------- From cayley.uwaterloo.ca!jmlait Thu Mar 27 06:49:41 1997 Return-Path: Received: from cayley.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wAGUi-000fJqC; Thu, 27 Mar 97 06:49 PST Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id JAA12833 for ; Thu, 27 Mar 1997 09:38:44 -0500 (EST) Date: Thu, 27 Mar 1997 09:38:44 -0500 (EST) From: Jeff Lait cc: Directors Subject: Re: Help! In-Reply-To: <9703191823.AA31027@regulus.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 19 Mar 1997 charles@krl.caltech.edu wrote: > > It has been over a month and a half since there has been any traffic on the > > ag-universe list, and I am completely out of ideas as to how to encourage > > participation. Our code is serviceable, but not complete. I can not > > finish the group's work by myself. Does anyone know how I can recruit > > programmers, or even people willing to test what we have so far? > > I agree that we're having a huge problem here. The main drawback from > advertising and getting an influx of people is that I have to maintain all > of the mailing lists by hand, and keep falling behind on it. Plus I'm not > allowed to maintain 'large' mailing lists on this system, which I'm sure > this would become if we advertised. Without going public, we already have > about 70 people on the lists! People are still asking to be added all the > time. I tell them the project is in a major lull, and then add them. > > So, what I'm asking now is if anyone knows where we could put the mailing > lists such that they would be automated. I've looked, and haven't had any > luck. I don't mind keeping the web pages up-to-date as I have time, but > the mailing lists are a real pain. > My brother has expressed a willingness to set up a listserver on his server. If you could send me the lists, I could attempt to set something up. Bandwidth is the only major consideration, as his connection is via a cable modem, not T1 :<. - Jeff Lait (SOL) From charles Thu Mar 27 09:54:45 1997 Return-Path: Received: from regulus.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wAJNl-000fJqC; Thu, 27 Mar 97 09:54 PST Received: by regulus.krl.caltech.edu; (5.65v3.0/1.1.8.2/07Apr95-0112PM) id AA18422; Thu, 27 Mar 1997 09:44:59 -0800 From: Message-Id: <9703271744.AA18422@regulus.krl.caltech.edu> Subject: Re: Help! To: jmlait@cayley.uwaterloo.ca (Jeff Lait) Date: Thu, 27 Mar 1997 09:44:59 -0800 (PST) Cc: ag-directors In-Reply-To: from "Jeff Lait" at Mar 27, 97 09:38:44 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 751 > My brother has expressed a willingness to set up a listserver on > his server. If you could send me the lists, I could attempt to set > something up. Bandwidth is the only major consideration, as his > connection is via a cable modem, not T1 :<. Hmmm... this sounds like it could work. Will his machine be on all the time and all of that? Also, it would (hopefully) only be a temporary solution; I should have a machine at work soon of my very own which I can put anything I feel like on. And Caltech has 3 T3's, so bandwidth won't be a problem... :-) But I just don't want to make any promises on when this will be, because I _should_ have gotten it already. So I'd guess about a month or two, but I really have no clue. --- Charles From undergrad.math.uwaterloo.ca!jmlait Sat Apr 5 21:40:53 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wDkgs-000fIrC; Sat, 5 Apr 97 21:40 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.7.6/8.7.3) with ESMTP id AAA16610 for ; Sun, 6 Apr 1997 00:29:05 -0500 (EST) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id AAA03096 for ; Sun, 6 Apr 1997 00:29:03 -0500 (EST) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sun, 6 Apr 1997 00:29:02 -0500 (EST) From: Jeff Lait To: Directors Subject: FE_Update woes. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII First, UNInitObj or similar has to set obj->pic to NULL before AS_InitializePic. (Or the latter changed) Next, it seems FE_Update now getss the SECTOR numbers of the center of the screen,not the absolute position. So how am I supposed to determine where to draw??? Also, what happened to 64x64 sectors, w/ SUBPOWER etc? Could someone give me the rational of the new method, especially with respect to non RISC processors? In case you are wondering, I'm integrating the FE with the current (0.8) universe code. - Jeff Lait (SOL) From compuserve.com!Adrian_Tymes Tue Apr 8 22:46:30 1997 Return-Path: Received: from dub-img-2.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wEqDB-000fIrC; Tue, 8 Apr 97 22:46 PDT Received: by dub-img-2.compuserve.com (8.6.10/5.950515) id BAA15716; Wed, 9 Apr 1997 01:34:35 -0400 Date: Wed, 9 Apr 1997 01:33:42 -0400 From: Adrian Tymes Subject: FE_Update woes. To: AG-Directors Message-ID: <199704090133_MC2-13FB-9379@compuserve.com> > First, UNInitObj or similar has to set obj->pic to NULL before >AS_InitializePic. (Or the latter changed) I thought there would be some bugs. UN_NewObject() will set object->pic to NULL when allocating a new object, after making sure object is not NULL. > Next, it seems FE_Update now getss the SECTOR numbers of the >center of the screen,not the absolute position. So how am I supposed to >determine where to draw??? The sector numbers passed in are to allow FE_Update to quickly see what objects it may have to draw, by only checking certain specific subsectors (namely, the one passed in, its neighbors, and possibly its neighbors' neighbors, depending on the dimensions of the player's viewport in universe coordinates). Player->x and Player->y will be the center of the screen, as always. > Also, what happened to 64x64 sectors, w/ SUBPOWER etc? Could >someone give me the rational of the new method, especially with respect to >non RISC processors? The universe code is platform independent; this includes not caring about RISC vs. CISC. We thought that the user might want to play on different sized universes, for instance, to see what happens in a small universe vs. a large universe. Since you asked, I'll change the default to 64*64 subsectors for now, but this and the size of the subsectors will probably wind up being user selectable parameters (albeit likely only selectable from powers of 2). Now that I look at it, there may be little merit to having a selectable subsector size. I'll have to think about it, to see if there was a better reason for that. > In case you are wondering, I'm integrating the FE with the current >(0.8) universe code. I'll incorporate any bugs you can find, then send the revised files. From compuserve.com!Adrian_Tymes Sat Apr 12 12:12:33 1997 Return-Path: Received: from dub-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wG8Du-000fIrC; Sat, 12 Apr 97 12:12 PDT Received: by dub-img-4.compuserve.com (8.6.10/5.950515) id PAA21419; Sat, 12 Apr 1997 15:00:36 -0400 Date: Sat, 12 Apr 1997 14:59:52 -0400 From: Adrian Tymes Subject: Re: FE_Update woes. To: AG-Directors Message-ID: <199704121500_MC2-1427-D8CF@compuserve.com> > Don't have the code here, but I presume that's a global? Why not >just pass either Player->x & Player->y in (As seems to have been the case >with v0.6) or Player. The former is nicer as it allows us to easily >display arbitrary sections of the screen without making a virtual player. >Determining subsector from abs position should be cheap, at least if >powers of two are used. Even if not, 2 divides a screen refresh is >beneath notice.A Ok, we'll switch to absolute position instead of subsector. > It's just divides are expensive, and shifts are cheap on x86 >systems. Shifts are cheap on many systems, not just x86. How about we pass in the number of shifts to use as well? Subsector size will be limited to a power of two, so (centerX >> shiftsX) == centerSubSectorX, and likewise for Y. How does this look for a FE_Update() prototype? FE_Ticks FE_Update(UN_Object* **Sectors, UN_Coord centerX, UN_Coord centerY, unsigned short shiftsX, unsigned short shiftsY); From undergrad.math.uwaterloo.ca!jmlait Sat Apr 12 15:09:38 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wGAzF-000fIrC; Sat, 12 Apr 97 15:09 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id RAA06191 for ; Sat, 12 Apr 1997 17:57:37 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id RAA26533 for ; Sat, 12 Apr 1997 17:57:34 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sat, 12 Apr 1997 17:57:33 -0400 (EDT) From: Jeff Lait cc: AG-Directors Subject: Re: FE_Update woes. In-Reply-To: <199704121500_MC2-1427-D8CF@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 12 Apr 1997, Adrian Tymes wrote: > > Don't have the code here, but I presume that's a global? Why not > >just pass either Player->x & Player->y in (As seems to have been the case > >with v0.6) or Player. The former is nicer as it allows us to easily > >display arbitrary sections of the screen without making a virtual player. > >Determining subsector from abs position should be cheap, at least if > >powers of two are used. Even if not, 2 divides a screen refresh is > >beneath notice.A > > Ok, we'll switch to absolute position instead of subsector. > > > It's just divides are expensive, and shifts are cheap on x86 > >systems. > > Shifts are cheap on many systems, not just x86. How about we pass in > the number of shifts to use as well? Subsector size will be limited to > a power of two, so (centerX >> shiftsX) == centerSubSectorX, and > likewise for Y. How does this look for a FE_Update() prototype? > > FE_Ticks FE_Update(UN_Object* **Sectors, > UN_Coord centerX, UN_Coord centerY, > unsigned short shiftsX, unsigned short shiftsY); > Looks froody. I'll implement this prototype. - Jeff Lait (SOL) From pop3.demon.co.uk!darkin Fri Jun 13 01:06:43 1997 Return-Path: Received: from punt-1.mail.demon.net by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wcRLB-000fIrC; Fri, 13 Jun 97 01:04 PDT Received: from darkin.demon.co.uk ([158.152.65.117]) by punt-1.mail.demon.net id aa0920011; 13 Jun 97 8:56 BST Message-Id: <1.5.4.32.19970613075626.006fcfd8@pop3.demon.co.uk> X-Sender: darkin@pop3.demon.co.uk (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Jun 1997 08:56:26 +0100 To: ag-directors@krl.caltech.edu From: Christian Darkin Subject: message from New Scientist Cc: ag-alife@krl.caltech.edu Hi, I just got this message from New Scientist (a very big science magazine in the UK): >Christian, > I work for New Scientist magazine and wanted to find out more about >P:VN and how things are going. > Hope you have time to help. > Regards > Mark Ward > >--------------------------------------------------------------------- >Mark Ward >Technology Correspondent >New Scientist Who should I pass him on to - somebody who knows what's happening on the Alife side would be good. Let me know as soon as you can. Cheers. Christian Darkin -- Christian Darkin christian@darkin.demon.co.uk Http://www.darkin.demon.co.uk/homepage.html From compuserve.com!Adrian_Tymes Fri Jun 13 20:29:27 1997 Return-Path: Received: from dub-img-6.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wcjWc-000fJsC; Fri, 13 Jun 97 20:29 PDT Received: by dub-img-6.compuserve.com (8.6.10/5.950515) id XAA00453; Fri, 13 Jun 1997 23:26:17 -0400 Date: Fri, 13 Jun 1997 23:25:59 -0400 From: Adrian Tymes Subject: message from New Scientist To: AG-Directors Message-ID: <199706132326_MC2-1879-BC4B@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline >Who should I pass him on to - somebody who knows what's happening on the= >Alife side would be good. Since the question has been asked, I'd like to know what's happening, too. Are the FE and AI groups getting any further? I've got useable, if slightly buggy, code for the universe, but I haven't been able to get anyone on my group to help test or debug.= From compuserve.com!Adrian_Tymes Sun Jun 15 11:45:59 1997 Return-Path: Received: from arl-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wdKIh-000fJsC; Sun, 15 Jun 97 11:45 PDT Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id OAA23370; Sun, 15 Jun 1997 14:42:15 -0400 Date: Sun, 15 Jun 1997 14:41:51 -0400 From: Adrian Tymes Subject: Re: message from New Scientist To: Christian Darkin Cc: AG-Directors Message-ID: <199706151441_MC2-1888-BEE9@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline >I think it's a pretty sorry state that we can't get anyone to debug the >code. We're now at a stage where people really ought to be getting exci= ted >about this project, and yet there seems to be silence all around. I wis= h I >could help, but I have no idea about code of any kind - I gave up >programming after 6502 machine code ! Even if you do not wish to debug, you may be able to test. If you have a DOS/Windows machine, or a C compiler, I can send you the program, and you could tell me whether or not it runs at all on a computer other than mine. I've put comments in the stub FE files that we're using until we get the real FE code; those comments, and the in-game text, should tell you how to play, if you wish to test whether the game runs correctly. I can't even get anyone to do that! >Let's go out and recruit some more people - I'm sure we could find them = if >we gave it a go. I'm still getting enquiries from the website. I've gotten a few inquiries myself, but they're either for other parts of the project - which I directed to the rest of you, depending on which part - or, if they are interested in the universe, they never show up on the mailing list, even months after I ask them to subscribe to it. (Just so I know I haven't forgotten: I direct subscription requests to Christian, correct?) >Christian Darkin >www.darkin.demon.co.uk/homepage.html= From undergrad.math.uwaterloo.ca!jmlait Sun Jun 15 16:23:06 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wdOdT-000fJyC; Sun, 15 Jun 97 16:23 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id TAA29500 for ; Sun, 15 Jun 1997 19:19:58 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id TAA17478 for ; Sun, 15 Jun 1997 19:19:56 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sun, 15 Jun 1997 19:19:55 -0400 (EDT) From: Jeff Lait cc: AG-Directors Subject: Re: message from New Scientist In-Reply-To: <199706132326_MC2-1879-BC4B@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 13 Jun 1997, Adrian Tymes wrote: > >Who should I pass him on to - somebody who knows what's happening on the > >Alife side would be good. > > Since the question has been asked, I'd like to know what's happening, > too. Are the FE and AI groups getting any further? I've got useable, > if slightly buggy, code for the universe, but I haven't been able to > get anyone on my group to help test or debug. My apologies, I was waiting for the file, but just realized that I had already recieved it (0.81, 4/19/97?). Sometimes automatic archival sucks... The FE group is where it was before, which is not very far. I had successfully integrated the FE with the universe code a couple months ago, but that was the old version and '95 trashed the directory (Quite worrisome.. I have off-site back-ups now so I should be able to avoid that now...) Last I heard from A-Life was a conclusion that this is not yet feasible. The message was: >From htrd@tcp.co.uk Thu Mar 20 06:34:12 1997 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by undergrad.math.uwaterloo.ca (8.7.6/8.7.3) with SMTP id GAA07507 for ; Thu, 20 Mar 1997 06:34:02 -0500 (EST) Received: from zeus.tcp.net.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0w7gB5-000fIrC; Thu, 20 Mar 97 03:38 PST Received: from ai036.du.pipex.com (ai036.du.pipex.com [193.130.248.36]) by zeus. tcp.net.uk (8.7.6/8.7) with SMTP id LAA24889 for ; Thu, 20 Mar 1997 11:28:13 GMT From: htrd@tcp.co.uk (Toby Dickenson) To: ag-directors@krl.caltech.edu Subject: Re: Help! Date: Thu, 20 Mar 1997 19:30:04 GMT Message-ID: <33318b24.592337890@mail.tcp.co.uk> References: <9703191823.AA31027@regulus.krl.caltech.edu> In-Reply-To: <9703191823.AA31027@regulus.krl.caltech.edu> X-Mailer: Forte Agent .99g/32.339 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO X-Status: A On Wed, 19 Mar 1997 10:23:09 -0800 (PST), you wrote: >> It has been over a month and a half since there has been any traffic on the >> ag-universe list, and I am completely out of ideas as to how to encourage >> participation. Our code is serviceable, but not complete. I can not >> finish the group's work by myself. Does anyone know how I can recruit >> programmers, or even people willing to test what we have so far? ag-alife has been idle to.... for so long that I had forgotten I was still subscribed. At one point both lists were quite busy. Do we know where people have gone, and why the traffic has died down? Speaking personally, my contributions stopped because I felt the project as it had developed would not succeed in its main goals. Not through lack of development effort, but for technical reasons. I am still interested in the ideal behind the project, which is why I originally sayed on the list, but don't feel I can offer development effort so something in which I see little chance of success. Perhaps other contributors feel similarly? Perhaps this would be the time to let the project die? (Sorry for the poor line feeds.) - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Sun Jun 15 16:36:21 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wdOqF-000fJyC; Sun, 15 Jun 97 16:36 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id TAA10606; Sun, 15 Jun 1997 19:33:11 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id TAA18411; Sun, 15 Jun 1997 19:33:08 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sun, 15 Jun 1997 19:33:07 -0400 (EDT) From: Jeff Lait cc: Christian Darkin , AG-Directors Subject: Re: message from New Scientist In-Reply-To: <199706151441_MC2-1888-BEE9@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 15 Jun 1997, Adrian Tymes wrote: > >I think it's a pretty sorry state that we can't get anyone to debug the > >code. We're now at a stage where people really ought to be getting excited > >about this project, and yet there seems to be silence all around. I wish I I'd say that stage was over two years ago when we were discussing fractal textures, morphing of ship designs, etc. > >could help, but I have no idea about code of any kind - I gave up > >programming after 6502 machine code ! > > Even if you do not wish to debug, you may be able to test. If you have > a DOS/Windows machine, or a C compiler, I can send you the program, and > you could tell me whether or not it runs at all on a computer other > than mine. I've put comments in the stub FE files that we're using > until we get the real FE code; those comments, and the in-game text, > should tell you how to play, if you wish to test whether the game runs > correctly. > > I can't even get anyone to do that! > Yes, my fault again... > >Let's go out and recruit some more people - I'm sure we could find them if > >we gave it a go. I'm still getting enquiries from the website. > > I've gotten a few inquiries myself, but they're either for other parts > of the project - which I directed to the rest of you, depending on > which part - or, if they are interested in the universe, they never > show up on the mailing list, even months after I ask them to subscribe New blood is not really a viable answer. "Adding more man power to a late software project makes it later". I've given quite a few side projects out to people to work on. Guess what my response rate has been: 0. Standard pattern is: new person: Good day, I'd like to work on the front end, I have some C/C++/whatever experience, and am eager to learn more. me: Great! Here's the latest code, and here's a list of stuff that needs to be done. What would you like? - Jeff Lait (SOL) From charles Tue Jun 17 08:30:17 1997 Return-Path: Received: from regulus.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0we0Cf-000fIrC; Tue, 17 Jun 97 08:29 PDT Received: by regulus.krl.caltech.edu; (5.65v3.0/1.1.8.2/07Apr95-0112PM) id AA10018; Tue, 17 Jun 1997 08:25:25 -0700 From: Message-Id: <9706171525.AA10018@regulus.krl.caltech.edu> Subject: Mail flood... To: ag-directors Date: Tue, 17 Jun 1997 08:25:25 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 979 Hi Folks. So, since this article appeared in the New Scientist, I've gotten an absolute flood of requests from people to join the mailing list. This poses me with three problems: 1) I don't really have the time to add all of them (by hand) to the select mailing lists they want, and still don't have access to machines with automated software. 2) There really are too many people who want to be part of the project, and I'm simply not allowed to run mailing lists of this size on any of these machines. 3) Most of them are asking lots of questions! Eeep! I've been trying to keep up, but there is just no way!!! If anyone would be willing to take over the mailing lists, I'd happily send them everything I have currently, and help anyway I can. I think problem #2 here is the biggest.... I'll also (obviously) update the web pages to reflect the changes. Plus I can have the current lists foward mail, so that wouldn't be a problem. --- Charles From phil.ruu.nl!Martijn.Faassen Tue Jun 17 10:49:24 1997 Return-Path: Received: from moe.serv.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0we2NZ-000fIrC; Tue, 17 Jun 97 10:49 PDT Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.141.23]) by moe.serv.phil.ruu.nl (8.8.5/8.8.5/KKm1.8) with ESMTP id TAA08219 for ; Tue, 17 Jun 1997 19:46:05 +0200 (MET DST) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.8.5/8.8.5/KKs1.6) id TAA27598 for ag-directors@krl.caltech.edu; Tue, 17 Jun 1997 19:46:03 +0200 (MET DST) From: Martijn Faassen Message-Id: <199706171746.TAA27598@laurel.stud.phil.ruu.nl> Subject: PvN: my take To: ag-directors@krl.caltech.edu Date: Tue, 17 Jun 1997 19:46:02 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi there, Looks like the people at New Scientist wanted to get the project going or something. :) Is there an ascii copy of what appeared there available somewhere? I'll try to find a copy of the magazine myself but am not sure if I'll be able to. Perceived problems: - Project's not moving. In my experience projects like this only move on when there are one or two people highly driven to do something, and willing to do most of the stuff themselves if nobody else does it. People like that tend to inspire others, and *something* is happening no matter who is helping, as the driven people do it anyway. Where do we find people like that? I *want* to invest much more time in this, but I do need to graduate Very Soon Now and I'm working on that and can't really spare much time for something else. Still, after I send off this mail I'll download the most up to date universe code and take a look at it. I don't know about the FE, but Alife is currently not doing much. There is a lot of code, but since Badcoe left some time ago and he was mostly responsible for that code, nobody has been looking into it yet. I myself don't have the time to dive into that code. I wish I did. What I will probably do anyway is whip up a simple (but evolvable) alife engine myself (but not the Genetic Programming one..which may have more potential than mine). Eventually. If I see a nice universe where it's easy to plug that engine into. :) So, one or more someones are needed to set their teeth in the alife code. - Mailflood of new applications, questions. Hm. I am not sure if I know any solution to this. Someone has a mailing list so people can join? Perhaps we can have application criteria, and if we don't see it happen we kick them off again? Still, there would need to be someone putting work into that. Someone on the project now, or someone who wants to join and looks very plausible. Perhaps we can send the interested people a 'join up form' (or perhaps have a web page for that), in which they can indicate what they are able to do and want to do. On the questions themselves, I myself am perfectly willing to try to answer some of them, let's say 5 for starters. Just mail 5 of them to me, Charles, and I'll do my best to answer them. If other people like to do the same thing those questions won't be that hard to deal with. - What we should focus on now is either get driven ourselves, or find people who are. Opinions on this are welcome. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From undergrad.math.uwaterloo.ca!jmlait Tue Jun 17 14:19:05 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0we5eK-000fIrC; Tue, 17 Jun 97 14:18 PDT Received: from herschel.math.uwaterloo.ca (jmlait@herschel.math.uwaterloo.ca [129.97.204.32]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id RAA25866 for ; Tue, 17 Jun 1997 17:15:36 -0400 (EDT) Received: from localhost (jmlait@localhost) by herschel.math.uwaterloo.ca (8.8.5/8.8.5) with SMTP id RAA22039 for ; Tue, 17 Jun 1997 17:15:35 -0400 (EDT) X-Authentication-Warning: herschel.math.uwaterloo.ca: jmlait owned process doing -bs Date: Tue, 17 Jun 1997 17:15:35 -0400 (EDT) From: Jeff Lait cc: ag-directors@krl.caltech.edu Subject: Re: PvN: my take In-Reply-To: <199706171746.TAA27598@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 Jun 1997, Martijn Faassen wrote: > > Hi there, > > Looks like the people at New Scientist wanted to get the project going or > something. :) Is there an ascii copy of what appeared there available > somewhere? I'll try to find a copy of the magazine myself but am not sure > if I'll be able to. > Agreed... > Perceived problems: > > - Project's not moving. In my experience projects like this only move on > when there are one or two people highly driven to do something, and willing to > do most of the stuff themselves if nobody else does it. People like that tend > to inspire others, and *something* is happening no matter who is helping, as > the driven people do it anyway. > > Where do we find people like that? I *want* to invest much more time in this, > but I do need to graduate Very Soon Now and I'm working on that > and can't really spare much time for something else. Still, after I send off > this mail I'll download the most up to date universe code and take a look at > it. Yes, how true. I have definitely not had the time to devote to this that I'd like to... If it ain't work, its school... > > I don't know about the FE, but Alife is currently not doing much. There is FE is attempting to integrate with Universe as we speak... > - Mailflood of new applications, questions. > > Hm. I am not sure if I know any solution to this. Someone has a mailing > list so people can join? Perhaps we can have application criteria, and if > we don't see it happen we kick them off again? Still, there would need to > be someone putting work into that. Someone on the project now, or someone > who wants to join and looks very plausible. Perhaps we can send the interested > people a 'join up form' (or perhaps have a web page for that), in which they > can indicate what they are able to do and want to do. > I have half a mailing list set up now, I'll try to see if I can get it working. Not sure how high volume it can take though... > On the questions themselves, I myself am perfectly willing to try to answer > some of them, let's say 5 for starters. Just mail 5 of them to me, Charles, > and I'll do my best to answer them. > Same here. > Opinions on this are welcome. You've pretty much summed it up. - Jeff Lait (SOL) From compuserve.com!Adrian_Tymes Tue Jun 17 18:45:50 1997 Return-Path: Received: from arl-img-8.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0we9ob-000fJyC; Tue, 17 Jun 97 18:45 PDT Received: by arl-img-8.compuserve.com (8.6.10/5.950515) id VAA01164; Tue, 17 Jun 1997 21:42:28 -0400 Date: Tue, 17 Jun 1997 21:41:34 -0400 From: Adrian Tymes Subject: Re: PvN: my take To: AG-Directors Message-ID: <199706172141_MC2-18AD-3EDA@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline > Yes, how true. I have definitely not had the time to devote to >this that I'd like to... If it ain't work, its school... I hear you. If it ain't work, it's work, work, or work. Being out of school isn't all that it is said to be. >> - Mailflood of new applications, questions. = Can we send mail to everyone on the list, asking them to respond if they want to remain on the list? I suspect that many of the addresses may be abandoned (valid, but no one reads them); if so, purging them should solve the size problem. Invalid addresses, of course, should also be removed. >> On the questions themselves, I myself am perfectly willing to try to a= nswer >> some of them, let's say 5 for starters. Just mail 5 of them to me, Cha= rles, >> and I'll do my best to answer them. >> = > Same here. I try to answer all questions sent my way. If I can not, I redirect them to someone who I think can answer them. I can easily handle more than five questions per week. Just how many questions are you getting, Charles?= From phil.ruu.nl!Martijn.Faassen Wed Jun 18 17:36:07 1997 Return-Path: Received: from moe.serv.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weVCk-000fK4C; Wed, 18 Jun 97 17:36 PDT Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.141.23]) by moe.serv.phil.ruu.nl (8.8.5/8.8.5/KKm1.8) with ESMTP id CAA18894 for ; Thu, 19 Jun 1997 02:32:44 +0200 (MET DST) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.8.5/8.8.5/KKs1.6) id CAA03456 for ag-directors@alnilam.krl.caltech.edu; Thu, 19 Jun 1997 02:32:43 +0200 (MET DST) From: Martijn Faassen Message-Id: <199706190032.CAA03456@laurel.stud.phil.ruu.nl> Subject: New Scientist article To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 19 Jun 1997 02:32:42 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi there, I did some net searching and found what is presumably the article at: http://www.newscientist.com/keysites/netropolitan/970614.html The text is reproduced here (there appears to be a picture but I can't view it with lynx :): --- cyberspace may be an infinite, unbounded territory, but so far it has been sadly lacking in explorers and star-faring civilisations. If you feel like playing God and breeding a race to conquer the electronic wastes sign up for Project:Von Neumann. The project takes its name from computer and electronics genius John von Neumann who in 1956 theorised about machines that could reproduce. In the same vein the game is based on breeding artificial creatures that can survive the rigours of Cyberspace warfare. Create a race and conquer the stars. --- Even better than advertising on Usenet! :) Was there someone who had had email from New Scientist asking about the status of this project? If so, we'd probably like to hear more details. Btw: I download the most recent copy of universe from our ftp site and compiled it. It compiles fine on my linux 1.2.8 machine, except that gcc gives quite a bunch of warnings. Oh, and a minor bug. In the fe.h file FE_Malloc and FE_Free are defined (note the capitals). In the fe.c file FE_malloc and FE_free occur instead. This gave a linking error, but changing the capitals in fe.c fixed that problem. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From undergrad.math.uwaterloo.ca!jmlait Wed Jun 18 17:48:33 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weVOo-000fK4C; Wed, 18 Jun 97 17:48 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id UAA16419 for ; Wed, 18 Jun 1997 20:45:13 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id UAA21452 for ; Wed, 18 Jun 1997 20:45:11 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Wed, 18 Jun 1997 20:45:11 -0400 (EDT) From: Jeff Lait cc: AG Directors Subject: Re: New Scientist article In-Reply-To: <199706190032.CAA03456@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jun 1997, Martijn Faassen wrote: > > Hi there, > > I did some net searching and found what is presumably the article at: > > http://www.newscientist.com/keysites/netropolitan/970614.html > > The text is reproduced here (there appears to be a picture but I can't > view it with lynx :): > It's a picture of three keyboards with mice attached. > Btw: I download the most recent copy of universe from our ftp site and > compiled it. It compiles fine on my linux 1.2.8 machine, except that > gcc gives quite a bunch of warnings. Oh, and a minor bug. > Yeah, you should see the number of warnings generated by int->short conversions when I linked in the real fe. > In the fe.h file FE_Malloc and FE_Free are defined (note the capitals). > In the fe.c file FE_malloc and FE_free occur instead. This gave a linking > error, but changing the capitals in fe.c fixed that problem. > Yes, FE_Malloc is the correct name. There was a discrepency a while ago. On other notes, I now have a purple square moving through space. Yeah! Unfortunately, there appears to have been some confusion re: scale, namely the old FE was working at a 1000:1 ratio re: the universe code. Hopefully when I fix that things will work.... - Jeff Lait (SOL) From phil.ruu.nl!Martijn.Faassen Wed Jun 18 18:11:35 1997 Return-Path: Received: from moe.serv.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weVl5-000fK4C; Wed, 18 Jun 97 18:11 PDT Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.141.23]) by moe.serv.phil.ruu.nl (8.8.5/8.8.5/KKm1.8) with ESMTP id DAA19563; Thu, 19 Jun 1997 03:08:08 +0200 (MET DST) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.8.5/8.8.5/KKs1.6) id DAA03626; Thu, 19 Jun 1997 03:08:04 +0200 (MET DST) From: Martijn Faassen Message-Id: <199706190108.DAA03626@laurel.stud.phil.ruu.nl> Subject: Re: FE changes To: ag-directors@alnilam.krl.caltech.edu (AG Directors), ag-universe@alnilam.krl.caltech.edu (ag universe) Date: Thu, 19 Jun 1997 03:08:03 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jeff Lait wrote: > > Btw: I download the most recent copy of universe from our ftp site and > > compiled it. It compiles fine on my linux 1.2.8 machine, except that > > gcc gives quite a bunch of warnings. Oh, and a minor bug. > > > Yeah, you should see the number of warnings generated by > int->short conversions when I linked in the real fe. I got various long->int conversions in the printf code (in the stub fe), and a few more serious problems, I think a warning on substracting a number that couldn't fit in a signed int (or long) so it was forced to pick an unsigned one. I'm not sure what the effects of this one are, though, yet. (it was in the universe code, I think the wrap around code) > Yes, FE_Malloc is the correct name. There was a discrepency a > while ago. > On other notes, I now have a purple square moving through space. Hey, I had purple squares moving through space with my SVGAlib testing FE long ago! :) And I actually had 'stick figure spaceships' moving around and rotating using Allegro (a graphics library) and DJGPP2.0 in dos. Then again, your proof of concept came from way before that again. :) More then agains, it didn't have collision detection either, and I think my ships ran out of energy after a bit of ineffectual blasting around. > Yeah! Unfortunately, there appears to have been some confusion re: scale, > namely the old FE was working at a 1000:1 ratio re: the universe code. > Hopefully when I fix that things will work.... This is probably my fault. I was always confused about this ratio business, still am (so elucidate), so I think I made universe do output to a 1024x786 screen (which could be converted to lower resolutions). However, Adrian seems to have removed that code again. Still, this may be causing the current problems. I just had the universe code assume one 'unit' in universe is identical to one pixel on a 1024x786 screen. Perhaps this is too implementation specific, though it could be converted to any lower resolution with the same aspect ratio. It *was* easy, though. :) This leads me to the following question: from my cursory glance at the newer universe code I couldn't figure out who figures out what part of the universe is displayed by the FE. In my original mock up FE I had the universe doing the main job: have a floating 'view' on the entire universe, 1024x786 universe units bit. The universe code would then go through all appropriate sectors and instruct the FE which objects were in view. This view area could float around with the player, or be located anywhere in universe (or follow another probe, or anything, really). I did have to make 'wall' edges of the universe instead of wrap around to make it work, I recall, though that may be merely have been ease of coding. How does it work in the current setup? How does the FE determine what parts of the universe to display? Ideally we would like an arbitrarily placeable view on the universe as described, but who is responsible for what? [I sent this mail to both directors and universe. It probably belongs in FE as well, but I'm not subscribed to that one] Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From phil.ruu.nl!Martijn.Faassen Wed Jun 18 18:14:21 1997 Return-Path: Received: from moe.serv.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weVnl-000fKQC; Wed, 18 Jun 97 18:14 PDT Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.141.23]) by moe.serv.phil.ruu.nl (8.8.5/8.8.5/KKm1.8) with ESMTP id DAA19752 for ; Thu, 19 Jun 1997 03:10:59 +0200 (MET DST) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.8.5/8.8.5/KKs1.6) id DAA03634 for ag-directors@alnilam.krl.caltech.edu; Thu, 19 Jun 1997 03:10:58 +0200 (MET DST) From: Martijn Faassen Message-Id: <199706190110.DAA03634@laurel.stud.phil.ruu.nl> Subject: Publicity mailing list? To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 19 Jun 1997 03:10:57 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi there, I just checked out the website and saw that Christian Darkin is responsible (according to that) the publicity aspects of the game. Perhaps we could start up a mailing list especially for people who want to handle all the publicity. Then we can simply put in the website the address of that mailing list to mail if you have more questions, and the publicity people can try to answer it. (obviously the publicity people would need to be on a few other list to be aware of what is going on..so they can answer any questions) Just an idea Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From phil.ruu.nl!Martijn.Faassen Wed Jun 18 18:20:43 1997 Return-Path: Received: from moe.serv.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weVtw-000fK5C; Wed, 18 Jun 97 18:20 PDT Received: from laurel.stud.phil.ruu.nl (laurel.stud.phil.ruu.nl [131.211.141.23]) by moe.serv.phil.ruu.nl (8.8.5/8.8.5/KKm1.8) with ESMTP id DAA20232 for ; Thu, 19 Jun 1997 03:17:22 +0200 (MET DST) Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.8.5/8.8.5/KKs1.6) id DAA03656 for ag-directors@alnilam.krl.caltech.edu; Thu, 19 Jun 1997 03:17:19 +0200 (MET DST) From: Martijn Faassen Message-Id: <199706190117.DAA03656@laurel.stud.phil.ruu.nl> Subject: Web page problems To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Thu, 19 Jun 1997 03:17:17 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I just looked quickly through our web pages and noted a few problems: - The archives link doesn't seem to function, so i can't access the mail archives (which is why I was at the pages in the first place). - The list of coordinators is not up to date: Grey Taylor: I haven't heard from him in a long time? Are you still there? I.Badcoe: While formerly very active in both alife and universe, and responsible for most of the alife code that we have, he changed jobs some time ago (went into game programming) and hasn't returned after that, unfortunately. I suppose that leaves me as the alife coordinator... Luckily that list is very silent right now. :) (if we find someone who has time to put some life back into it I'll be glad to relinquish this coordinator position) Mike Mitchener of the ag-mac group? Is he still around? Same for Stuart McDonald. I just see there is an ag-unix group. I'd love to join that one. I appear to be the one who coded a unix (linux) front end and only now I hear about this group. Charles, could you join me? Note: This is my last mail for the week, probably. I volunteer various other people to continue this flurry of mails after I'm gone. Who? You know who you are. :) We shouldn't lose the bit of momentum we have right now. Back next week, and good luck, Martijn -- Martijn Faassen email:faassen@phil.ruu.nl Pessimist's Definition of Optimism : Failing to learn from life. Optimist's Definition of Pessimism : Failing to learn to live. From compuserve.com!Adrian_Tymes Wed Jun 18 19:11:35 1997 Return-Path: Received: from hil-img-3.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weWgd-000fK7C; Wed, 18 Jun 97 19:10 PDT Received: by hil-img-3.compuserve.com (8.6.10/5.950515) id WAA18267; Wed, 18 Jun 1997 22:07:43 -0400 Date: Wed, 18 Jun 1997 22:07:09 -0400 From: Adrian Tymes Subject: Re: FE changes To: AG-Directors , AG-Universe Message-ID: <199706182207_MC2-18C4-BA67@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline >> Yeah, you should see the number of warnings generated by >> int->short conversions when I linked in the real fe. > >I got various long->int conversions in the printf code (in the stub fe),= and >a few more serious problems, I think a warning on substracting a number = that >couldn't fit in a signed int (or long) so it was forced to pick an unsig= ned >one. I'm not sure what the effects of this one are, though, yet. >(it was in the universe code, I think the wrap around code) Could you give me a list of file names, line numbers, and errors, please, so I can fix these problems? I get no errors when I compile. >More then agains, it didn't have collision detection either, and I think= >my ships ran out of energy after a bit of ineffectual blasting around. = Regeneration has not been added yet. Do we want automatic energy regeneration, or should probes only be able to refuel by eating? >This leads me to the following question: from my cursory glance at the n= ewer >universe code I couldn't figure out who figures out what part of the = >universe is displayed by the FE. I thought that was supposed to be FE's job: determine which subsectors fit on the screen given the platform and user settings, then display those subsectors.= From undergrad.math.uwaterloo.ca!jmlait Wed Jun 18 19:28:17 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weWxF-000fKQC; Wed, 18 Jun 97 19:28 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id WAA04812 for ; Wed, 18 Jun 1997 22:24:52 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id WAA24178 for ; Wed, 18 Jun 1997 22:24:50 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Wed, 18 Jun 1997 22:24:50 -0400 (EDT) From: Jeff Lait cc: AG Directors Subject: Re: Web page problems In-Reply-To: <199706190117.DAA03656@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jun 1997, Martijn Faassen wrote: > I suppose that leaves me as the alife coordinator... Luckily that list is > very silent right now. :) (if we find someone who has time to put some life > back into it I'll be glad to relinquish this coordinator position) > Good luck, I've been trying to get out of Art-Sound for two years now :> - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed Jun 18 19:36:25 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weX4k-000fKQC; Wed, 18 Jun 97 19:35 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id WAA26044; Wed, 18 Jun 1997 22:32:37 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id WAA24483; Wed, 18 Jun 1997 22:32:35 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Wed, 18 Jun 1997 22:32:35 -0400 (EDT) From: Jeff Lait cc: AG Directors , ag universe Subject: Re: FE changes In-Reply-To: <199706190108.DAA03626@laurel.stud.phil.ruu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jun 1997, Martijn Faassen wrote: > > Jeff Lait wrote: > > > Yes, FE_Malloc is the correct name. There was a discrepency a > > while ago. > > On other notes, I now have a purple square moving through space. > > Hey, I had purple squares moving through space with my SVGAlib testing > FE long ago! :) And I actually had 'stick figure spaceships' moving around > and rotating using Allegro (a graphics library) and DJGPP2.0 in dos. > Well, I just hacked as.c, so: > Then again, your proof of concept came from way before that again. :) > I now have proof of concept remade. 'cept the enemy ships move differently from the star fields, and it appears the universe has a different idea of clockwise than I do... > More then agains, it didn't have collision detection either, and I think > my ships ran out of energy after a bit of ineffectual blasting around. > I think there is collision detection, as when I fire, my player immediately dies... > > Yeah! Unfortunately, there appears to have been some confusion re: scale, > > namely the old FE was working at a 1000:1 ratio re: the universe code. > > Hopefully when I fix that things will work.... > > This is probably my fault. I was always confused about this ratio > business, still am (so elucidate), so I think I made universe do output > to a 1024x786 screen (which could be converted to lower resolutions). However, > Adrian seems to have removed that code again. Still, this may be causing the > current problems. > > I just had the universe code assume one 'unit' in universe is identical to > one pixel on a 1024x786 screen. Perhaps this is too implementation specific, > though it could be converted to any lower resolution with the same aspect > ratio. It *was* easy, though. :) The trouble is the universe requires some fractional bits. Way back when, I thought we had decided on 16 fractional bits, 1024x1024 screens, and 64 sectors, each one screen in size. Now it seems to be 6 fractional bits, screens 1024x1024, and 64 by 64 sectors. Anyone confirm? > > This leads me to the following question: from my cursory glance at the newer > universe code I couldn't figure out who figures out what part of the > universe is displayed by the FE. In my original mock up FE I had the > universe doing the main job: have a floating 'view' on the entire universe, > 1024x786 universe units bit. The universe code would then go through all > appropriate sectors and instruct the FE which objects were in view. This > view area could float around with the player, or be located anywhere in > universe (or follow another probe, or anything, really). I did have to make > 'wall' edges of the universe instead of wrap around to make it work, I recall, > though that may be merely have been ease of coding. > > How does it work in the current setup? How does the FE determine what parts > of the universe to display? Ideally we would like an arbitrarily placeable > view on the universe as described, but who is responsible for what? The universe code now calls FE_Update with PlayerX, PlayerY, which represent the center of the view area. It also gives shiftx and shifty, which is the amount to shift right to get the sector numbers from this. There are only two problems currently: 1) It is up to the FE to decide dimmensions displayed, this is nor real problem, I do a 64kx64k universe unit area centred on the specified coords. 2) More seriously, the FE is not told what the dimmensions of the universe are. I had to hard code 65536*64 to get around this... > > [I sent this mail to both directors and universe. It probably belongs in FE > as well, but I'm not subscribed to that one] I think I am the only active person on the FE, so that is irrelevant. Just keep it on directors, as I am not on universe. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Wed Jun 18 19:42:05 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weXA8-000fKgC; Wed, 18 Jun 97 19:41 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id WAA19075; Wed, 18 Jun 1997 22:38:11 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id WAA24728; Wed, 18 Jun 1997 22:38:09 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Wed, 18 Jun 1997 22:38:08 -0400 (EDT) From: Jeff Lait cc: AG-Directors , AG-Universe Subject: Re: FE changes In-Reply-To: <199706182207_MC2-18C4-BA67@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Jun 1997, Adrian Tymes wrote: > >More then agains, it didn't have collision detection either, and I think > >my ships ran out of energy after a bit of ineffectual blasting around. > > Regeneration has not been added yet. Do we want automatic energy > regeneration, or should probes only be able to refuel by eating? > So that's why I didn't find the repleneshiment of energy code. More importantly, and along these lines, the ApplyPhysics, et la assume a constant frame rate! While maintaining one is a good idea, the actual frame rate achieved will likely vary from computer to computer. All the velocity, energy regeneration, TURN RATE, etc, should be updated dependent on the time elapsed since the last round. Shouldn't they? As it stands now, I finally put the timer code in, but found it was entirely unused... > >This leads me to the following question: from my cursory glance at the newer > >universe code I couldn't figure out who figures out what part of the > >universe is displayed by the FE. > > I thought that was supposed to be FE's job: determine which subsectors > fit on the screen given the platform and user settings, then display > those subsectors. It is, see my other reply. - Jeff Lait (SOL) From pop3.demon.co.uk!darkin Thu Jun 19 04:09:09 1997 Return-Path: Received: from punt-1.mail.demon.net by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wef5I-000fJsC; Thu, 19 Jun 97 04:09 PDT Received: from darkin.demon.co.uk ([158.152.65.117]) by punt-1.mail.demon.net id aa0915077; 19 Jun 97 9:00 BST Message-Id: <1.5.4.32.19970619075836.0067ff44@pop3.demon.co.uk> X-Sender: darkin@pop3.demon.co.uk (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 1997 08:58:36 +0100 To: ag-directors@krl.caltech.edu From: Christian Darkin Subject: Re: PvN: my take At 21:41 17/06/97 -0400, you wrote: >> Yes, how true. I have definitely not had the time to devote to >>this that I'd like to... If it ain't work, its school... > >I hear you. If it ain't work, it's work, work, or work. Being out of >school isn't all that it is said to be. > >>> - Mailflood of new applications, questions. > >Can we send mail to everyone on the list, asking them to respond if >they want to remain on the list? I suspect that many of the addresses >may be abandoned (valid, but no one reads them); if so, purging them >should solve the size problem. Invalid addresses, of course, should >also be removed. As I suggested a while back, why don't we archive all the addresses into a list and then de-subscribe everyone except a core of people who really want to get involved. Then we can send everyone else a kind of digest (like every couple of months, or so) just to keep them up to date for whatever phase of the project they're waiting to join in with. Then we can still keep the people without clogging up Charles' lists. Of course, this still does leave the problem of manually subscribed lists, and someone's going to have to do that work, but it looks like we need a short term fix right now. Christian -- Christian Darkin christian@darkin.demon.co.uk Http://www.darkin.demon.co.uk/homepage.html From atcon.com!henning Thu Jun 19 07:04:53 1997 Return-Path: Received: from loki.atcon.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wehpP-000fJsC; Thu, 19 Jun 97 07:04 PDT Received: from temp.atcon.com (ts1-d153.han.atcon.com [199.126.229.153]) by loki.atcon.com (8.8.5/1.359) with SMTP id KAA28115 for ; Thu, 19 Jun 1997 10:01:27 -0400 (EDT) Date: Thu, 19 Jun 1997 10:01:27 -0400 (EDT) Message-Id: <199706191401.KAA28115@loki.atcon.com> X-Sender: henning@mail.atcon.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ag-directors@alnilam.krl.caltech.edu From: henning@atcon.com Subject: a radical thought Hi: I think the VonNeumann projects is really cool in its conception - but I have my doubts about your implementation strategy. I have followed the universe and alife lists (I'm not on this list, but thought it might be the most appropriate to write to with my beef) for over a year now, and it seems to me the project is not coming along fast enough to really keep up with the development of technology. I have written 3 fully playable games with self-organizing monsters (which have genes and could easily been made to evolve too) last winter, and am trying to bring the ideas tested there together into what i hope will be a commercial product. I have started writing that in Direct3D retained mode, and that is a platform that looks really beautiful. It runs too slow on my computer which has no 3D video card as of now, but I figure for release in 2 years time it makes sense to target computers with 3D video cards. Direct3D looks like it will be well supported on all Windows computers. It is so much easier to write to such a high level platform than to use your approach of coding everything yourself in ANSI C. How do you plan to interface to modern 3D video cards? Or will you ignore their capabilities? Then your game will likely be slow and old-fashioned looking when it comes out... So, once in a while it is time to rethink the strategy on every project. I think you should seriously consider switching to OpenGL or Direct3D. Your program will then be able to run on 90% of all computers instead of all of them, but who cares? All serious gamers run Windows95 and DirectX as of now... Please understand that I write this because I like your project and think you are a bunch of really cool guys, and that I wish you the best. If you respond to the list, please send me a copy, so I know what you think about this. Best wishes, Peter Henningsen From wronski.math.uwaterloo.ca!jmlait Thu Jun 19 08:44:16 1997 Return-Path: Received: from wronski.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wejNd-000fJyC; Thu, 19 Jun 97 08:44 PDT Received: from localhost (jmlait@localhost) by wronski.math.uwaterloo.ca (8.8.5/8.8.5) with SMTP id LAA06044; Thu, 19 Jun 1997 11:43:44 -0400 (EDT) Date: Thu, 19 Jun 1997 11:43:44 -0400 (EDT) From: Jeff Lait To: henning@atcon.com cc: ag-directors@alnilam.krl.caltech.edu Subject: Re: a radical thought In-Reply-To: <199706191401.KAA28115@loki.atcon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jun 1997 henning@atcon.com wrote: > Hi: > on all Windows computers. It is so much easier to write to such a high level > platform than to use your approach of coding everything yourself in ANSI C. > How do you plan to interface to modern 3D video cards? Or will you ignore > their capabilities? Then your game will likely be slow and old-fashioned > looking when it comes out... This game is not 3d. And while we could use the 3d capabilities to render the bitmaps, trying to hit the moving mark called DirectX would be even more difficult. As for being old fashioned looking, yeah, but graphical quality was not the main goal of this. And, as for being slow, it is quite the opposite. My own machine has sped up by about a factor of 18 since this started. This is a good thing, though, as we need the cycles for the AI (If that part is done...) Drawing a few dozen transparent rotated bitmaps in software is quite a reasonable goal for todays machines, with plenty of cycles left for other stuff. > So, once in a while it is time to rethink the strategy on every > project. I think you should seriously consider switching to OpenGL or > Direct3D. Your program will then be able to run on 90% of all computers > instead of all of them, but who cares? All serious gamers run Windows95 and > DirectX as of now... This project is decidedly non-commercial. Besides, keep in mind this project started when WinG was new & hot. (Win95 was still in Beta as well, and you can understand the reluctance to go for Win3.1) Where would we be if we had decided to go for WinG? Well, around 5 or so rewrites of the FE to keep up with the API changes. As it is, after writing POC III (I thinkt hat was the number) quite a while back, I've only had to keep up with changes in the Universe API, and that was hard enough IMHO. > Please understand that I write this because I like your project and > think you are a bunch of really cool guys, and that I wish you the best. If > you respond to the list, please send me a copy, so I know what you think > about this. No problem. I can understand where your coming from, and wish you luck with your future endeavours. If you should desire to write a DirectX front end for this, it would be appreciated. - Jeff Lait (SOL) From charles Thu Jun 19 09:12:50 1997 Return-Path: Received: from regulus.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wejpI-000fJsC; Thu, 19 Jun 97 09:12 PDT Received: by regulus.krl.caltech.edu; (5.65v3.0/1.1.8.2/07Apr95-0112PM) id AA26767; Thu, 19 Jun 1997 09:11:06 -0700 From: Message-Id: <9706191611.AA26767@regulus.krl.caltech.edu> Subject: Re: PvN: my take To: darkin@pop3.mail.demon.net (Christian Darkin) Date: Thu, 19 Jun 1997 09:11:06 -0700 (PDT) Cc: ag-directors@krl.caltech.edu In-Reply-To: <1.5.4.32.19970619075836.0067ff44@pop3.demon.co.uk> from "Christian Darkin" at Jun 19, 97 08:58:36 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1441 > As I suggested a while back, why don't we archive all the addresses into a > list and then de-subscribe everyone except a core of people who really want > to get involved. Then we can send everyone else a kind of digest (like > every couple of months, or so) just to keep them up to date for whatever > phase of the project they're waiting to join in with. Okay, I like this. > Then we can still keep the people without clogging up Charles' lists. > > Of course, this still does leave the problem of manually subscribed lists, > and someone's going to have to do that work, but it looks like we need a > short term fix right now. How's this for a deal; I'll knock down the number of mailing lists (There really isn't enough traffic on them to warrent all of them anyway - if that changes then we can work something new out). In the meantime how about this: ag-design - general project von-neumann list ag-directors - list for the core group keeping the game going ag-announce - people just periferally interested in the game. I'll then setup a CGI script to interface with these lists which is password protected. When someone new subscribes up, anyone will be able to add them to the lists so the work can be split up among people who have time to do it.... I'll make sure all of the directors have the password. It may take me a bit to write the script, but I'll try to get to it soon. Sound good? --- Charles From compuserve.com!Adrian_Tymes Thu Jun 19 19:42:13 1997 Return-Path: Received: from dub-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wete1-000fJsC; Thu, 19 Jun 97 19:41 PDT Received: by dub-img-4.compuserve.com (8.6.10/5.950515) id WAA06449; Thu, 19 Jun 1997 22:41:22 -0400 Date: Thu, 19 Jun 1997 22:41:06 -0400 From: Adrian Tymes Subject: Re: FE changes To: AG-Universe Cc: AG-Directors Message-ID: <199706192241_MC2-18CA-5B5E@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline > I now have proof of concept remade. 'cept the enemy ships move >differently from the star fields, and it appears the universe has a >different idea of clockwise than I do... The first could be good. Isn't that effect known as "parallax"? As for the second, 0 degrees is up (positive y), 90 degrees is right (positive x), and so forth. Would it be more work to change FE or to change UN? > I think there is collision detection, as when I fire, my player >immediately dies... I haven't put in the initial displacement for stationary firers code yet. You have to get your ship up to speed; the bullet appears two "moves" ahead of you at the moment. Check UN_FireWeapon() in unobject.c for the exact implementation of this. > Now it seems to be 6 fractional bits, screens 1024x1024, and 64 by >64 sectors. Anyone confirm? 64 * 64 sectors, each 65536 * 65536 universe coordinates in size. For a 1024 * 1024 pixel screen and 1 sector per screen, this would be 6 fractional bits. These are the default settings at the moment. > 1) It is up to the FE to decide dimmensions displayed, this is >nor real problem, I do a 64kx64k universe unit area centred on the >specified coords. > 2) More seriously, the FE is not told what the dimmensions of the >universe are. I had to hard code 65536*64 to get around this... The universe has several global variables, possibly adjustable by the user, which define this: size_x,size_y: dimensions of the universe size_sectx,size_secty: dimensions of a sector shitfs_x,shifts_y: the number of bits to shift to change a coordinate to a sector number Should these be passed (or set) as part of FE_InitSystem()?= From compuserve.com!Adrian_Tymes Thu Jun 19 19:42:16 1997 Return-Path: Received: from dub-img-4.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wete2-000fJyC; Thu, 19 Jun 97 19:41 PDT Received: by dub-img-4.compuserve.com (8.6.10/5.950515) id WAA06460; Thu, 19 Jun 1997 22:41:23 -0400 Date: Thu, 19 Jun 1997 22:41:10 -0400 From: Adrian Tymes Subject: Re: FE changes To: AG-Universe Cc: AG-Directors Message-ID: <199706192241_MC2-18CA-5B5F@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline [Is there anyone still active on the ag-universe list who is not also on the ag-directors list?] > More importantly, and along these lines, the ApplyPhysics, et la >assume a constant frame rate! While maintaining one is a good idea, the= >actual frame rate achieved will likely vary from computer to computer. >All the velocity, energy regeneration, TURN RATE, etc, should be updated= >dependent on the time elapsed since the last round. Shouldn't they? The code assumes that AI's execution time per frame will vary to use up whatever FE and UN do not, thus assuring a constant frame rate. Is this assumption still valid? > As it stands now, I finally put the timer code in, but found it >was entirely unused... It was designed to be used by AI. Since the stub AI does nothing, anything passed only to it is not used.= From compuserve.com!Adrian_Tymes Thu Jun 19 19:42:17 1997 Return-Path: Received: from dub-img-10.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0weteM-000fJzC; Thu, 19 Jun 97 19:42 PDT Received: by dub-img-10.compuserve.com (8.6.10/5.950515) id WAA02443; Thu, 19 Jun 1997 22:41:42 -0400 Date: Thu, 19 Jun 1997 22:41:13 -0400 From: Adrian Tymes Subject: Re: PvN: my take To: AG-Directors Message-ID: <199706192241_MC2-18CA-5B60@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline >How's this for a deal; I'll knock down the number of mailing lists (Ther= e >really isn't enough traffic on them to warrent all of them anyway - if t= hat >changes then we can work something new out). In the meantime how about >this: > > ag-design - general project von-neumann list > ag-directors - list for the core group keeping the game going > ag-announce - people just periferally interested in the game. > >I'll then setup a CGI script to interface with these lists which is >password protected. When someone new subscribes up, anyone will be able= to >add them to the lists so the work can be split up among people who have = time >to do it.... I'll make sure all of the directors have the password. I like it. The ag-design list would be where we put the "I want to code" newcomers until they actually do some coding, right? Likewise, the not infrequent people who say they can code, but dissapear once given a list of the things we need done, would be moved to just the ag-announce list after a certain time, correct? One suggestion, if my interpretation is correct: make the ag-announce and ag-design lists auto-subscribe/unsubscribe ones, which anyone can subscribe and remove themselves from. Of course, we would also have passwords to remove anyone from those lists (for instance, silent addresses).= From sqf.hp.com!smd Thu Jun 19 23:41:22 1997 Return-Path: Received: from palrel1.hp.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wexNn-000fJsC; Thu, 19 Jun 97 23:41 PDT Received: from hpqs0236.sqf.hp.com (smd@hpqs0236.sqf.hp.com [15.144.177.110]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id XAA15064 for ; Thu, 19 Jun 1997 23:40:50 -0700 (PDT) Received: by hpqs0236.sqf.hp.com (1.37.109.20/15.5+ECS 3.4 ) id AA125288847; Fri, 20 Jun 1997 07:40:47 +0100 From: Stuart McDonald Message-Id: <199706200640.AA125288847@hpqs0236.sqf.hp.com> Subject: Re: PvN: my take To: ag-directors@krl.caltech.edu Date: Fri, 20 Jun 1997 7:40:47 BST X-Mailer: Elm [revision: 109.14] > >changes then we can work something new out). In the meantime how about > >this: > > > > ag-design - general project von-neumann list > > ag-directors - list for the core group keeping the game going > > ag-announce - people just periferally interested in the game. > > > >I'll then setup a CGI script to interface with these lists which is > >password protected. When someone new subscribes up, anyone will be able= > to > >add them to the lists so the work can be split up among people who have = > time > >to do it.... I'll make sure all of the directors have the password. > > I like it. The ag-design list would be where we put the "I want to > code" newcomers until they actually do some coding, right? Likewise, > the not infrequent people who say they can code, but dissapear once > given a list of the things we need done, would be moved to just the > ag-announce list after a certain time, correct? I also like this idea. Can I also say that though I've been silent I have still been following the project. The current status of the X-lib FE interface is there isn't one, but since the FE seems to change with each revision.... I am still willing to put time into coding, but I think we really need someone looking at the AI side of things. The "ship-flying-round-space" could be coded by one person fairly easily (indeed most of it was), it's the defining/agreeing on the various interfaces that has made it take so long (how long ago was POC written?). It's the AI aspect that makes this game, and without some strong commitment in that area then I don't see the point of the rest it. I would far rather see a bunch on single pixels on single screen which move around and somehow "evolve behaviour" than a 3D rendered spaceship flying around..... I should still have the AI Language manual and the AI code somewhere, and could probably have a go a writing nodes, but I don't understand how it works etc and if we are going to continue using it then someone has to understand it. The alternative is to use some other method (I have no knowledge in this area). Cheers, Stuart. -- Stuart McDonald :: HP - TSD SQF Scotland :: smd@sqf.hp.com 10 INPUT A " Aaah, the good old 20 INPUT B: POKE A,B: LET A=A+1: GOTO 20 days..." From pop3.demon.co.uk!darkin Fri Jun 20 05:20:49 1997 Return-Path: Received: from punt-2.mail.demon.net by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wf2gH-000fJsC; Fri, 20 Jun 97 05:20 PDT Received: from darkin.demon.co.uk ([158.152.65.117]) by punt-2.mail.demon.net id aa0525505; 20 Jun 97 11:56 BST Message-Id: <1.5.4.32.19970620105442.006fec08@pop3.demon.co.uk> X-Sender: darkin@pop3.demon.co.uk (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Jun 1997 11:54:42 +0100 To: ag-directors@alnilam.krl.caltech.edu From: Christian Darkin Subject: Re: Publicity mailing list? At 03:10 19/06/97 +0200, you wrote: > >Hi there, > >I just checked out the website and saw that Christian Darkin is responsible >(according to that) the publicity aspects of the game. Perhaps we could >start up a mailing list especially for people who want to handle all the >publicity. Then we can simply put in the website the address of that mailing >list to mail if you have more questions, and the publicity people can try >to answer it. (obviously the publicity people would need to be on a few >other list to be aware of what is going on..so they can answer any questions) When somebody has questions about the project, they should really talk to the people doing the coding. I could have tried to answer New Scientist's queries myself, but really, it's best to pass people on to the experts in the group on whatever subject they're interested in. What I'm doing at the moment, is getting emails from people interested in the project, answering basic queries, and then passing people on to whoever can deal with them. I'm not going out looking for publicity right now, although I do occasionally suggest membership drives and the like - When we need more people, I'll start plugging it :) Christian Darkin www.darkin.demon.co.uk/homepage.html > >Just an idea > >Martijn >-- >Martijn Faassen email:faassen@phil.ruu.nl >Pessimist's Definition of Optimism : Failing to learn from life. >Optimist's Definition of Pessimism : Failing to learn to live. > -- Christian Darkin christian@darkin.demon.co.uk Http://www.darkin.demon.co.uk/homepage.html From pop3.demon.co.uk!darkin Fri Jun 20 05:39:38 1997 Return-Path: Received: from punt-2.mail.demon.net by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wf2yT-000fJsC; Fri, 20 Jun 97 05:39 PDT Received: from darkin.demon.co.uk ([158.152.65.117]) by punt-2.mail.demon.net id aa0525469; 20 Jun 97 11:56 BST Message-Id: <1.5.4.32.19970620105439.006fb838@pop3.demon.co.uk> X-Sender: darkin@pop3.demon.co.uk (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Jun 1997 11:54:39 +0100 To: AG Directors From: Christian Darkin Subject: Re: New Scientist article At 02:32 19/06/97 +0200, you wrote: > >Hi there, > >I did some net searching and found what is presumably the article at: > >http://www.newscientist.com/keysites/netropolitan/970614.html > >The text is reproduced here (there appears to be a picture but I can't >view it with lynx :): > I just brought a copy of New Scientist - That's the article, but there's no picture. Maybe the online piece has a pic. I'll check. > >Even better than advertising on Usenet! :) > >Was there someone who had had email from New Scientist asking about the >status of this project? If so, we'd probably like to hear more details. That would be me. I think the guy must have emailled me after he wrote the piece, so it sounds like a bigger story might be on the cards. If that's going to happen, I need to get back to him with some people he can talk to about the specifics of alife. Anyone who can help there would be useful. > >Btw: I download the most recent copy of universe from our ftp site and >compiled it. It compiles fine on my linux 1.2.8 machine, except that >gcc gives quite a bunch of warnings. Oh, and a minor bug. > >In the fe.h file FE_Malloc and FE_Free are defined (note the capitals). >In the fe.c file FE_malloc and FE_free occur instead. This gave a linking >error, but changing the capitals in fe.c fixed that problem. I don't have a compiler, but if somebody can point me at one, I'll give it a go too. > >Martijn >-- >Martijn Faassen email:faassen@phil.ruu.nl >Pessimist's Definition of Optimism : Failing to learn from life. >Optimist's Definition of Pessimism : Failing to learn to live. > -- Christian Darkin christian@darkin.demon.co.uk Http://www.darkin.demon.co.uk/homepage.html From undergrad.math.uwaterloo.ca!jmlait Fri Jun 20 07:21:37 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wf4ZC-000fJsC; Fri, 20 Jun 97 07:21 PDT Received: from herschel.math.uwaterloo.ca (jmlait@herschel.math.uwaterloo.ca [129.97.204.32]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id KAA03936 for ; Fri, 20 Jun 1997 10:20:59 -0400 (EDT) Received: from localhost (jmlait@localhost) by herschel.math.uwaterloo.ca (8.8.5/8.8.5) with SMTP id KAA03711 for ; Fri, 20 Jun 1997 10:20:58 -0400 (EDT) X-Authentication-Warning: herschel.math.uwaterloo.ca: jmlait owned process doing -bs Date: Fri, 20 Jun 1997 10:20:57 -0400 (EDT) From: Jeff Lait To: Directors Subject: Re: FE changes In-Reply-To: <199706192241_MC2-18CA-5B5F@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jun 1997, Adrian Tymes wrote: > [Is there anyone still active on the ag-universe list who is not also > on the ag-directors list?] > > > More importantly, and along these lines, the ApplyPhysics, et la > >assume a constant frame rate! While maintaining one is a good idea, the > >actual frame rate achieved will likely vary from computer to computer. > >All the velocity, energy regeneration, TURN RATE, etc, should be updated > >dependent on the time elapsed since the last round. Shouldn't they? > > The code assumes that AI's execution time per frame will vary to use up > whatever FE and UN do not, thus assuring a constant frame rate. Is > this assumption still valid? > It could be valid if it weren't for the fact that this does not now occur. Thus, there is no bound on the frame rate. What is the desired DPS? Running at 100+ FPS the turning is still a bit slow IMO. > > As it stands now, I finally put the timer code in, but found it > >was entirely unused... > > It was designed to be used by AI. Since the stub AI does nothing, > anything passed only to it is not used. I believe I understand. I'll add some code to said AI to while for the next frame... - Jeff Lait (SOL) From charles Sat Jun 21 14:17:25 1997 Return-Path: Received: from regulus.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wfXWp-000fJsC; Sat, 21 Jun 97 14:17 PDT Received: by regulus.krl.caltech.edu; (5.65v3.0/1.1.8.2/07Apr95-0112PM) id AA32523; Sat, 21 Jun 1997 14:15:15 -0700 From: Message-Id: <9706212115.AA32523@regulus.krl.caltech.edu> Subject: Re: PvN: my take To: Adrian_Tymes@compuserve.com (Adrian Tymes) Date: Sat, 21 Jun 1997 14:15:15 -0700 (PDT) Cc: ag-directors@krl.caltech.edu In-Reply-To: <199706192241_MC2-18CA-5B60@compuserve.com> from "Adrian Tymes" at Jun 19, 97 10:41:13 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1282 > I like it. The ag-design list would be where we put the "I want to > code" newcomers until they actually do some coding, right? Likewise, > the not infrequent people who say they can code, but dissapear once > given a list of the things we need done, would be moved to just the > ag-announce list after a certain time, correct? Sounds about right. Most descussion would take place on ag-design, I'd guess. > One suggestion, if my interpretation is correct: make the ag-announce > and ag-design lists auto-subscribe/unsubscribe ones, which anyone can > subscribe and remove themselves from. Of course, we would also have > passwords to remove anyone from those lists (for instance, silent > addresses).= The whole problem is that I can't automate any of the lists. What I can do, however is make a web-page interface for the textfiles. The problem there is that I can't do any kind of varification to stop people from signing up a million times, unsubscirbing other people, etc. So I was going to just password protect it and have everyone on the directors list be able to maintain it. Then we can divide up the work.... Ideally, eventually, someone will join the list who has access to a list- server which we can transfer the project over to... --- Charles From undergrad.math.uwaterloo.ca!jmlait Sun Jun 22 05:33:11 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wflp8-000fJsC; Sun, 22 Jun 97 05:32 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id IAA30984; Sun, 22 Jun 1997 08:32:10 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id IAA21714; Sun, 22 Jun 1997 08:32:09 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sun, 22 Jun 1997 08:32:09 -0400 (EDT) From: Jeff Lait cc: AG-Universe , AG-Directors Subject: Re: FE changes In-Reply-To: <199706192241_MC2-18CA-5B5E@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jun 1997, Adrian Tymes wrote: > > I now have proof of concept remade. 'cept the enemy ships move > >differently from the star fields, and it appears the universe has a > >different idea of clockwise than I do... > > The first could be good. Isn't that effect known as "parallax"? > Not when it is a factor of 20... The closest stars should be at the same speed as stationary objects. > As for the second, 0 degrees is up (positive y), 90 degrees is right > (positive x), and so forth. Would it be more work to change FE or to > change UN? > There is the problem. I'm working in standard screen coordinates, with the origin in the upper left, hence, up is NEGATIVE y. It is an 8 character change in UN, as far as I can tell (Swap left and right). But the same in the FE (swap key codes being sent.) > > I think there is collision detection, as when I fire, my player > >immediately dies... > > I haven't put in the initial displacement for stationary firers code > yet. You have to get your ship up to speed; the bullet appears two > "moves" ahead of you at the moment. Check UN_FireWeapon() in > unobject.c for the exact implementation of this. > I thought I tried it with a moving ship and was still dumped to the you have died screen. > > Now it seems to be 6 fractional bits, screens 1024x1024, and 64 by > >64 sectors. Anyone confirm? > > 64 * 64 sectors, each 65536 * 65536 universe coordinates in size. For > a 1024 * 1024 pixel screen and 1 sector per screen, this would be 6 > fractional bits. These are the default settings at the moment. > Good. > > 1) It is up to the FE to decide dimmensions displayed, this is > >nor real problem, I do a 64kx64k universe unit area centred on the > >specified coords. > > 2) More seriously, the FE is not told what the dimmensions of the > >universe are. I had to hard code 65536*64 to get around this... > > The universe has several global variables, possibly adjustable by the > user, which define this: > size_x,size_y: dimensions of the universe > size_sectx,size_secty: dimensions of a sector > shitfs_x,shifts_y: the number of bits to shift to change a coordinate > to a sector number > > Should these be passed (or set) as part of FE_InitSystem()? I would prefer that. I really don't like sharing globals between the FE and the rest of the program, we should try to isolate the FE as far as possible from the vagaries of the UN (Actually, that should go the other way around, but so far its seemed to go that way) - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Sun Jun 22 05:38:41 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wflug-000fJzC; Sun, 22 Jun 97 05:38 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id IAA27500; Sun, 22 Jun 1997 08:38:00 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id IAA21733; Sun, 22 Jun 1997 08:37:59 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sun, 22 Jun 1997 08:37:58 -0400 (EDT) From: Jeff Lait cc: AG-Universe , AG-Directors Subject: Re: FE changes In-Reply-To: <199706192241_MC2-18CA-5B5F@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 19 Jun 1997, Adrian Tymes wrote: > [Is there anyone still active on the ag-universe list who is not also > on the ag-directors list?] > Well, I know the converse is untrue. > > More importantly, and along these lines, the ApplyPhysics, et la > >assume a constant frame rate! While maintaining one is a good idea, the > >actual frame rate achieved will likely vary from computer to computer. > >All the velocity, energy regeneration, TURN RATE, etc, should be updated > >dependent on the time elapsed since the last round. Shouldn't they? > > The code assumes that AI's execution time per frame will vary to use up > whatever FE and UN do not, thus assuring a constant frame rate. Is > this assumption still valid? > My concern is that with slower machines, we may wish to drop the frame rate to allow the AI time to breathe. Not only this, but this technique means ALL implementations of the FE must run at the same frame rate, or more precisely, all implementations of this game. I would much rather the FE provide via ticks the number of, say, milliseconds elapsed so far (Not necessarily accurate that far, but within a frame) The UN could then judge itself how many FPS to run at, possible user controlled, possible via feedback of how long the FE is taking. > > As it stands now, I finally put the timer code in, but found it > >was entirely unused... > > It was designed to be used by AI. Since the stub AI does nothing, > anything passed only to it is not used. Nonetheless, the turn rate seems quite inconsitent with the thrust rate, at least judging by delta with fixed objects (Though I still have to see what is going on there) - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Sun Jun 22 06:00:11 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wfmCy-000fK0C; Sun, 22 Jun 97 05:57 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id IAA00856; Sun, 22 Jun 1997 08:56:22 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id IAA21815; Sun, 22 Jun 1997 08:56:21 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sun, 22 Jun 1997 08:56:21 -0400 (EDT) From: Jeff Lait To: Stuart McDonald cc: ag-directors@krl.caltech.edu Subject: Re: PvN: my take In-Reply-To: <199706200640.AA125288847@hpqs0236.sqf.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 20 Jun 1997, Stuart McDonald wrote: > > Can I also say that though I've been silent I have still been following > the project. The current status of the X-lib FE interface is there isn't > one, but since the FE seems to change with each revision.... > Amen to that. It seems to have settled down now though.. But maybe that is due to reduced work on the UN? :> > I am still willing to put time into coding, but I think we really need > someone looking at the AI side of things. The "ship-flying-round-space" > could be coded by one person fairly easily (indeed most of it was), it's > the defining/agreeing on the various interfaces that has made it take > so long (how long ago was POC written?). Let's see, it was in BC3.0, so must have been... Nov 16, 1994. (Yeah, I cheated and checked the time stamps.) Note that version DID have a bunch of single pixels on the screen moving around... POC III, whose core routines exist unchanged to this day, was written around May 22nd, 1995. Since then, the only major changes have been a succession of api changes... >It's the AI aspect that makes > this game, and without some strong commitment in that area then I don't > see the point of the rest it. > > I would far rather see a bunch on single pixels on single screen which > move around and somehow "evolve behaviour" than a 3D rendered spaceship > flying around..... Agreed. But, we have lacked even those pixels. Further, to test the AI at all, the physics end (UN) must be there. Not all the fancy menus etc, which is why I was turned off by the earlier universes, around 0.42 or so, which seemed to concentrate on this and not the actual game play. I'm leaving FE_PlayMovie, FE_PointerBlah, etc, as stubs until I see some working AI which justifies making them. > > I should still have the AI Language manual and the AI code somewhere, > and could probably have a go a writing nodes, but I don't understand > how it works etc and if we are going to continue using it then someone > has to understand it. The alternative is to use some other method (I > have no knowledge in this area). Is anyone here aware of anyone working on the AI? Even if evolution is not successful, a cool enough editable enemy intelligence might make it worthwhile... When I track down the last few problems with the current FE/UN hybridization, we could try adding in the AI half if enough of it is coded (Is enough of the UN there though?) - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Sun Jun 22 06:36:40 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wfmoj-000fJsC; Sun, 22 Jun 97 06:36 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id JAA02990 for ; Sun, 22 Jun 1997 09:35:55 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id JAA22435 for ; Sun, 22 Jun 1997 09:35:54 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sun, 22 Jun 1997 09:35:53 -0400 (EDT) From: Jeff Lait Reply-To: Jeff Lait cc: Directors Subject: Re: PvN: my take In-Reply-To: <9706212115.AA32523@regulus.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 21 Jun 1997 charles@krl.caltech.edu wrote: > Ideally, eventually, someone will join the list who has access to a list- > server which we can transfer the project over to... I have some good news on this front. As alluded to earlier, I have access to a list server. When the IP becomes fixed (We were having occasional black outs with the dynamic IP system), we should be able to move over there. It runs under MajorDomo, and has the auto-subscribe, confirm, and removal features we desire. - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Sun Jun 22 08:06:10 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wfoDP-000fJsC; Sun, 22 Jun 97 08:06 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id LAA28177 for ; Sun, 22 Jun 1997 11:05:29 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id LAA23232 for ; Sun, 22 Jun 1997 11:05:27 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sun, 22 Jun 1997 11:05:27 -0400 (EDT) From: Jeff Lait To: Directors Subject: Integrated FE available... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Try: http://www.zincland.ml.org/~jmlait/EVILUTIO.ZIP NOTE CAPS! This has the Dos exe, which has been tested under 95, and whose timer routine likely doesn't set properly in OS/2. It also has all the OBJ files for those who can't compile the ASM but can handle Watcom based C*. It also has the *.ERR files, which list all warnings generated on compilation, which someone here desired to see. The AI is set to while in a null loop to maintain at most 90fps (My machine tops out around 190, undoubtably due to the bus and poor video card) - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Sun Jun 22 08:57:09 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wfp0j-000fJsC; Sun, 22 Jun 97 08:57 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id LAA26857; Sun, 22 Jun 1997 11:56:27 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id LAA24173; Sun, 22 Jun 1997 11:56:25 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Sun, 22 Jun 1997 11:56:25 -0400 (EDT) From: Jeff Lait To: ag-universe@krl.caltech.edu cc: Directors Subject: Re: Integrated FE available... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 22 Jun 1997, Jeff Lait wrote: > Try: > http://www.zincland.ml.org/~jmlait/EVILUTIO.ZIP > NOTE CAPS! > compilation, which someone here desired to see. The AI is set to while in > a null loop to maintain at most 90fps (My machine tops out around 190, > undoubtably due to the bus and poor video card) Well, about 59% of the time was used blitting to the video card, and 36% reading the joystick. I really need a joystick with faster capaciters... The real reason for this second post is to point out that I made several changes to the universe code, where either I thought there were bugs, or in order to get this to work. Could those on that team please run a diff and update me re: what changes you'll keep? - Jeff Lait (SOL) From undergrad.math.uwaterloo.ca!jmlait Tue Jun 24 09:01:28 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wgY1j-000fJyC; Tue, 24 Jun 97 09:01 PDT Received: from germain.math.uwaterloo.ca (jmlait@germain.math.uwaterloo.ca [129.97.204.33]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id MAA21972; Tue, 24 Jun 1997 12:00:11 -0400 (EDT) Received: from localhost (jmlait@localhost) by germain.math.uwaterloo.ca (8.8.5/8.8.5) with SMTP id MAA12814; Tue, 24 Jun 1997 12:00:10 -0400 (EDT) X-Authentication-Warning: germain.math.uwaterloo.ca: jmlait owned process doing -bs Date: Tue, 24 Jun 1997 12:00:09 -0400 (EDT) From: Jeff Lait To: Directors , henning@atcon.com Subject: Re: vonNeumann comments from the sideline cont'd In-Reply-To: <199706241158.HAA05887@loki.atcon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 24 Jun 1997 henning@atcon.com wrote: > > No problem. I can understand where your coming from, and wish you > >luck with your future endeavours. If you should desire to write a DirectX > >front end for this, it would be appreciated. > > Hi Jeff: > I see with pleasure that you're being busy on vonNeumann and that > the project is moving ahead. Writing such a front end might be good fun, if It is, which is why of course that I'm working on the DOS one. I'd be tempted to do a DirectX one, but do not have the time to learn its API. > That is without 3D video hardware. I've read about video cards that should > be able to run my entire game at over 60 fps though... the cutting edge > today... see what tomorrow brings... > Aye, the one good thing is that machines are only getting faster. > You wrote: My concern is that with slower machines, we may wish to drop the > >frame rate to allow the AI time to breathe. Not only this, but this > >technique means ALL implementations of the FE must run at the same frame > >rate, or more precisely, all implementations of this game. I would much > >rather the FE provide via ticks the number of, say, milliseconds elapsed > >so far (Not necessarily accurate that far, but within a frame) > > The UN could then judge itself how many FPS to run at, possible > >user controlled, possible via feedback of how long the FE is taking. > > The solution used in Microsoft's sample game Rockem, which is very > foolproof and elegant and I guess state of the art in game programming > today, is for the distance of all movements to be scaled by the time used > for the last cycle. This does not give you a constant frame rate, but the > best variable rate you can attain. You can also use the frame rate achieved Yes. This is exactly what I requested in an earlier message, but that was Naysayed by the universe crowd. Still, one must remember that a steady 30fps is better than 20-40 fps, for the mind is good at noticing these alterations in game speed. > by this method as a variable to reduce the detail of the display (or even > the number of probes in the game), so as to have the game run optimally on > all computers. All that is rather easy to program and failsafe in all > situations. With a fixed framerate on a multitasking operating system, when > the system takes a timeslice for its own arcane operations, the movement > would become jerky. Also, I would not trust an approach that aims to > maintain a fixed framerate and breaks down if it is not attained. In my > prototype games, I used a timer for the movements that was supposed to give > me a 30 fps framerate. I programmed and tested everything happily in the > debugger, and when i was done and made a release build, everything moved > with uncanny speed. Obviously my rather extensive AI was using more time and > the game was not really running at the timer rate in the debugger, the AI > not being finished yet when the next timer event fired... LOL... to fix > that, I would have actually had to put a finer grid on my world to allow my > monsters to make more movements per second... so I started designing a world > with variable granularity, which is a pain in the neck... I'm really glad to > simply program with floats now... Some nice arguements there. As for floating point, couldn't agree more. If we were to restart the project now, I would definitely insist on floating point coordinates. But, when it was started, there were still plenty of 486sxs around. - Jeff Lait (SOL) From compuserve.com!Adrian_Tymes Tue Jun 24 23:35:11 1997 Return-Path: Received: from arl-img-8.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wglfI-000fJyC; Tue, 24 Jun 97 23:34 PDT Received: by arl-img-8.compuserve.com (8.6.10/5.950515) id CAA29250; Wed, 25 Jun 1997 02:34:03 -0400 Date: Wed, 25 Jun 1997 02:33:47 -0400 From: Adrian Tymes Subject: Re: vonNeumann comments from the sideline cont'd To: AG-Directors Message-ID: <199706250233_MC2-1924-AF29@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline > Some nice arguements there. As for floating point, couldn't agree >more. If we were to restart the project now, I would definitely insist = on >floating point coordinates. But, when it was started, there were still >plenty of 486sxs around. = Are you sure that, even with modern processors, floating point to integer conversions would be faster than simple bit shifts? We've = already got variable granularity (at least, variable between sessions of the game), and it didn't seem too hard to code. From undergrad.math.uwaterloo.ca!jmlait Wed Jun 25 08:42:59 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wguDg-000fJyC; Wed, 25 Jun 97 08:42 PDT Received: from hypatia.math.uwaterloo.ca (jmlait@hypatia.math.uwaterloo.ca [129.97.204.31]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id LAA23241 for ; Wed, 25 Jun 1997 11:42:04 -0400 (EDT) Received: from localhost (jmlait@localhost) by hypatia.math.uwaterloo.ca (8.8.5/8.8.5) with SMTP id LAA16096 for ; Wed, 25 Jun 1997 11:42:01 -0400 (EDT) X-Authentication-Warning: hypatia.math.uwaterloo.ca: jmlait owned process doing -bs Date: Wed, 25 Jun 1997 11:42:00 -0400 (EDT) From: Jeff Lait cc: AG-Directors Subject: Re: vonNeumann comments from the sideline cont'd In-Reply-To: <199706250233_MC2-1924-AF29@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Jun 1997, Adrian Tymes wrote: > > Some nice arguements there. As for floating point, couldn't agree > >more. If we were to restart the project now, I would definitely insist on > >floating point coordinates. But, when it was started, there were still > >plenty of 486sxs around. > > Are you sure that, even with modern processors, floating point to > integer conversions would be faster than simple bit shifts? We've > already got variable granularity (at least, variable between sessions > of the game), and it didn't seem too hard to code. > No, conversions would be slower, but in the physics engine it would be faster, the addition of a delta_t term would be very cheap and easy to add. - Jeff Lait (SOL) From pop3.demon.co.uk!darkin Tue Jul 1 02:00:34 1997 Return-Path: Received: from punt-1.mail.demon.net by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wiym8-000fK8C; Tue, 1 Jul 97 01:59 PDT Received: from darkin.demon.co.uk ([158.152.65.117]) by punt-1.mail.demon.net id aa0923194; 1 Jul 97 9:54 BST Message-Id: <1.5.4.32.19970701085548.007096d4@pop3.demon.co.uk> X-Sender: darkin@pop3.demon.co.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 01 Jul 1997 09:55:48 +0100 To: ag-directors@krl.caltech.edu From: Christian Darkin Subject: intro video Hi, I've just been messing about with some new bits of desktop video kit, and I've put together a little sequence for the opening of the game. I hope to do a lot more eventually to make up a complete opening story with a few actors voices, and some digitised video. For now, I've put together a short (about 1 minute) sequence of the launch of the original Von Neunman Probe - It's all done with computer graphics (3D Studio Max, if you're interested) and a bit of original music. I've uploaded it to the FTP site - so if Charles could move it somewhere sensible... Thanks. The zipped file is about 1.3 meg - That's right, 1.3 meg for over a minute of video at 10 frames per second - that's pretty good compression (the new Indeo Interactive compression codec). Anyway, check it out and let me know what you think. Christian. -- Christian Darkin christian@darkin.demon.co.uk Http://www.darkin.demon.co.uk/homepage.html From charles Tue Jul 1 08:33:59 1997 Return-Path: Received: from regulus.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wj4w2-000fK8C; Tue, 1 Jul 97 08:33 PDT Received: by regulus.krl.caltech.edu; (5.65v3.0/1.1.8.2/07Apr95-0112PM) id AA20000; Tue, 1 Jul 1997 08:31:21 -0700 From: Message-Id: <9707011531.AA20000@regulus.krl.caltech.edu> Subject: Re: intro video To: darkin@pop3.mail.demon.net (Christian Darkin) Date: Tue, 1 Jul 1997 08:31:21 -0700 (PDT) Cc: ag-directors In-Reply-To: <1.5.4.32.19970701085548.007096d4@pop3.demon.co.uk> from "Christian Darkin" at Jul 1, 97 09:55:48 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1254 Hi folks. I've moved this to: ftp://ftp.krl.caltech.edu/pub/alife-game/program/movie.zip For those of you who want to grab it. I tried to take a look, but I still need to figure out where to get the de-compression software Christian refers to... --- Charles > Hi, > > I've just been messing about with some new bits of desktop video kit, and > I've put together a little sequence for the opening of the game. I hope to > do a lot more eventually to make up a complete opening story with a few > actors voices, and some digitised video. For now, I've put together a short > (about 1 minute) sequence of the launch of the original Von Neunman Probe - > It's all done with computer graphics (3D Studio Max, if you're interested) > and a bit of original music. I've uploaded it to the FTP site - so if > Charles could move it somewhere sensible... Thanks. > > The zipped file is about 1.3 meg - That's right, 1.3 meg for over a minute > of video at 10 frames per second - that's pretty good compression (the new > Indeo Interactive compression codec). > > Anyway, check it out and let me know what you think. > > > Christian. > -- > Christian Darkin > christian@darkin.demon.co.uk > Http://www.darkin.demon.co.uk/homepage.html > > From charles Tue Jul 1 12:55:08 1997 Return-Path: Received: from rigel.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wj90v-000fK8C; Tue, 1 Jul 97 12:55 PDT Received: by rigel.krl.caltech.edu; (5.65v3.0/1.1.8.2/21Mar95-1007AM) id AA31633; Tue, 1 Jul 1997 12:55:14 -0700 From: Message-Id: <9707011955.AA31633@rigel.krl.caltech.edu> Subject: Re: intro video To: jmlait@undergrad.math.uwaterloo.ca (Jeff Lait) Date: Tue, 1 Jul 1997 12:55:12 -0700 (PDT) Cc: ag-directors In-Reply-To: from "Jeff Lait" at Jul 1, 97 03:43:30 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 635 > I can't get this with anon ftp, permissions seem to be wrong. Fixed, sorry 'bout that. For some reason, things in the upload directory seem to start out with poor permissions. > > For those of you who want to grab it. I tried to take a look, but I still > > need to figure out where to get the de-compression software Christian refers > > to... > > > I've just uploaded the updated version as EVILUTIO.ZIP, this is > the integrated fe with un that I announced a while back, but hadn't got > around to putting it on the ftp site... This is also moved to the programs directory (with the proper permissions) --- Charles From compuserve.com!Adrian_Tymes Thu Jul 3 21:41:09 1997 Return-Path: Received: from hil-img-9.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wk0Aj-000fJqC; Thu, 3 Jul 97 21:40 PDT Received: (from mailgate@localhost) by hil-img-9.compuserve.com (8.8.6/8.8.6/2.1) id AAA20044; Fri, 4 Jul 1997 00:39:15 -0400 (EDT) Date: Fri, 4 Jul 1997 00:38:49 -0400 From: Adrian Tymes Subject: Re: Integrated FE available... To: AG-Universe Cc: AG-Directors Message-ID: <199707040039_MC2-19CB-4208@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline > The real reason for this second post is to point out that I made >several changes to the universe code, where either I thought there were >bugs, or in order to get this to work. Could those on that team please >run a diff and update me re: what changes you'll keep? Sorry for taking as long as I did on this, but I wanted to double check the code. From the file dates, it looks like only ungame.c and unobject.c were changed from 0.81; is this correct? If so, all the changes that I saw in those two files were acceptable, and if they're needed to get the code to work, then they will stay. The code so far seems to be more-or-less bug free, although I have encountered a couple of errors when running the executable included in the zip (operating environment: DOS w/o joystick): 1: Start the game, select "quit" - game exits with "Invalid call to FE_DisplayError". Apparently caused by the FE_DisplayError(0) call near the end of FE_PointerStatus() when the quit key is pushed. 2: Start the game, select "new", play around for a couple of minutes - game crashes, freezing system. The error messages look like a memory allocation error, which suggests a memory leak. Other than that (and the fact that the keyboard controls lack a fire key, which prevents me from testing firing), the game seems to run ok. Thus I ask, which features should we add next? Breeding and eating seem to be good candidates, as do on-screen status readouts (player's current health and energy, radar, et cetera).= From undergrad.math.uwaterloo.ca!jmlait Thu Jul 3 22:50:47 1997 Return-Path: Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wk1G1-000fJqC; Thu, 3 Jul 97 22:50 PDT Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by undergrad.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id BAA03865; Fri, 4 Jul 1997 01:48:47 -0400 (EDT) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id BAA06859; Fri, 4 Jul 1997 01:48:46 -0400 (EDT) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Fri, 4 Jul 1997 01:48:45 -0400 (EDT) From: Jeff Lait cc: AG-Universe , AG-Directors Subject: Re: Integrated FE available... In-Reply-To: <199707040039_MC2-19CB-4208@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Jul 1997, Adrian Tymes wrote: > > The real reason for this second post is to point out that I made > >several changes to the universe code, where either I thought there were > >bugs, or in order to get this to work. Could those on that team please > >run a diff and update me re: what changes you'll keep? > > Sorry for taking as long as I did on this, but I wanted to double check No problem. > the code. From the file dates, it looks like only ungame.c and > unobject.c were changed from 0.81; is this correct? If so, all the > changes that I saw in those two files were acceptable, and if they're > needed to get the code to work, then they will stay. > There are also changes to as.c and ai.c, primarily to load the bitmap & to actually use the ticks result. > The code so far seems to be more-or-less bug free, although I have > encountered a couple of errors when running the executable included in > the zip (operating environment: DOS w/o joystick): > 1: Start the game, select "quit" - game exits with "Invalid call to > FE_DisplayError". Apparently caused by the FE_DisplayError(0) call > near the end of FE_PointerStatus() when the quit key is pushed. Known error. In some cases, the universe requires a "yes" to quit as opposed to "Quit" (In player die, I think). I just hooked quit to immediately quit to avoid hanging my machine. > 2: Start the game, select "new", play around for a couple of minutes - > game crashes, freezing system. The error messages look like a memory > allocation error, which suggests a memory leak. I guess I never played it long enough... Can't think of anything that is allocated dynamically, more likely it is stepping on something. > Other than that (and the fact that the keyboard controls lack a fire > key, which prevents me from testing firing), the game seems to run ok. > Try using a joystick. > Thus I ask, which features should we add next? Breeding and eating > seem to be good candidates, as do on-screen status readouts (player's > current health and energy, radar, et cetera). Some on screen readouts are definitly required. - Jeff Lait (SOL) From compuserve.com!Adrian_Tymes Thu Jul 10 19:01:09 1997 Return-Path: Received: from arl-img-10.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0wmV0p-000fJyC; Thu, 10 Jul 97 19:00 PDT Received: (from mailgate@localhost) by arl-img-10.compuserve.com (8.8.6/8.8.6/2.1) id VAA28826 for ag-directors@krl.caltech.edu; Thu, 10 Jul 1997 21:58:52 -0400 (EDT) Date: Thu, 10 Jul 1997 21:58:42 -0400 From: Adrian Tymes Subject: ALife article To: AG-Directors Message-ID: <199707102158_MC2-1AA5-21F5@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Someone a bit more knowledgeable in ALife than myself might want to check out the sites mentioned in http://www.wired.com/news/news/wiredview/story/5037.html We might be able to recruit somebody to help with the AI, or at least get some ideas for what approach we want to take.= From compuserve.com!Adrian_Tymes Sun Nov 30 11:02:10 1997 Return-Path: Received: from arl-img-5.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0xcEci-000fUcC; Sun, 30 Nov 97 11:01 PST Received: (from root@localhost) by arl-img-5.compuserve.com (8.8.6/8.8.6/2.9) id NAA15547; Sun, 30 Nov 1997 13:50:23 -0500 (EST) Date: Sun, 30 Nov 1997 13:49:55 -0500 From: Adrian Tymes Subject: Status of P:VN? Sender: Adrian Tymes To: AG-Directors Cc: AG-Universe Message-ID: <199711301350_MC2-2A26-8D21@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline I have had no luck in my efforts to attract new blood for our work, and at the moment, the universe code is in stasis. At this point, if it is unlikely that I can get some help in the near future, I will have to formally end my commitment to this project. My apologies, but circumstances in my life mean that I can only continue here if something is happening. If anyone wants to take over as universe coordinator, I can send a copy of the "latest" (but a bit dated) code. If anyone would like to assist in programming - *AND WILL COMPLETE THE CODE THAT THEY PROMISE TO WRITE* (which over 50% of those who have promised me such have not done, so before you ask this, make sure you have enough free time and commitment to the project so that you can do what you say) - then ask, and I will be happy to reccomend a small piece to start with, one which even a beginning programmer could likely do in a day, at most (which is about the size of the assignments I've been giving out).= From undergrad.math.uwaterloo.ca!jmlait Mon Dec 1 06:41:17 1997 Return-Path: Received: from wronski.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0xcX20-000fVFC; Mon, 1 Dec 97 06:41 PST Received: from cayley.uwaterloo.ca (jmlait@cayley.uwaterloo.ca [129.97.204.6]) by wronski.math.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id JAA07975; Mon, 1 Dec 1997 09:29:33 -0500 (EST) Received: from localhost (jmlait@localhost) by cayley.uwaterloo.ca (8.8.5/8.8.5) with SMTP id JAA23521; Mon, 1 Dec 1997 09:29:32 -0500 (EST) X-Authentication-Warning: cayley.uwaterloo.ca: jmlait owned process doing -bs Date: Mon, 1 Dec 1997 09:29:31 -0500 (EST) From: Jeff Lait To: Adrian Tymes cc: AG-Directors , AG-Universe Subject: Re: Status of P:VN? In-Reply-To: <199711301350_MC2-2A26-8D21@compuserve.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 30 Nov 1997, Adrian Tymes wrote: > I have had no luck in my efforts to attract new blood for our work, and > at the moment, the universe code is in stasis. At this point, if it is > unlikely that I can get some help in the near future, I will have to > formally end my commitment to this project. My apologies, but > circumstances in my life mean that I can only continue here if > something is happening. If anyone wants to take over as universe > coordinator, I can send a copy of the "latest" (but a bit dated) code. > If anyone would like to assist in programming - *AND WILL COMPLETE THE > CODE THAT THEY PROMISE TO WRITE* (which over 50% of those who have > promised me such have not done, so before you ask this, make sure you > have enough free time and commitment to the project so that you can do > what you say) - then ask, and I will be happy to reccomend a small You've got a 50% succeess rate? Better than I've seen... > piece to start with, one which even a beginning programmer could likely > do in a day, at most (which is about the size of the assignments I've > been giving out). Ah, I went itno this project execting it to fail, as the vast majority of such things do. Mind you, it has lasted a HECK of a lot longer than I expected, and progressed a lot farther than I exected as well. But, I alsowent into this promissing myself I would restrict myself to the FE side of things, so I'm afraid I will not commit any time to working on said code. It might be time to shut the project down. - Jeff Lait (SOL) From darkin.demon.co.uk!christian Tue Dec 2 07:34:34 1997 Return-Path: Received: from post.mail.demon.net by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0xcuKY-000fW5C; Tue, 2 Dec 97 07:33 PST Received: from darkin.demon.co.uk ([158.152.65.117]) by post.mail.demon.net id aa1027002; 2 Dec 97 15:15 GMT From: Christian Darkin To: Adrian Tymes , AG-Directors Cc: AG-Universe Subject: Re: Status of P:VN? Date: Tue, 2 Dec 1997 09:46:00 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <881075725.1027002.0@darkin.demon.co.uk> ---------- From: Adrian Tymes To: AG-Directors Cc: AG-Universe Subject: Status of P:VN? Date: 30 November 1997 18:49 Hi, Ok, I guess the thing to do now would be to get a report on the status of the project and the work that's been done from FE, Universe and Alife (just one paragraph would do), and compile it into a post. We can then send that out to the newsgroups with a general request for suggestions: Either from people willing to take over, or help out - or from university or school groups - or even games companies - who want to use our ideas and work. After all, that was always the intention - to make all our code and ideas public domain: We've done a lot of work on this, and at least some of it is bound to be of interest to somebody - That is if people don't turn up in droves wanting to help out! Christian Darkin ---------- From compuserve.com!Adrian_Tymes Tue Dec 2 19:16:32 1997 Return-Path: Received: from dub-img-2.compuserve.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0xd5Ia-000fWUC; Tue, 2 Dec 97 19:16 PST Received: (from root@localhost) by dub-img-2.compuserve.com (8.8.6/8.8.6/2.9) id WAA25430; Tue, 2 Dec 1997 22:04:56 -0500 (EST) Date: Tue, 2 Dec 1997 22:04:33 -0500 From: Adrian Tymes Subject: Re: Status of P:VN? Sender: Adrian Tymes To: AG-Directors Cc: AG-Universe Message-ID: <199712022204_MC2-2A79-4C3F@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline >> If anyone would like to assist in programming - *AND WILL COMPLETE THE= >> CODE THAT THEY PROMISE TO WRITE* (which over 50% of those who have >> promised me such have not done, so before you ask this, make sure you >> have enough free time and commitment to the project so that you can do= >> what you say) - then ask, and I will be happy to reccomend a small > > You've got a 50% succeess rate? Better than I've seen... No, I had a less than 50% sucess rate. While I don't have the exact figures, I suspect it was somewhere around 10 to 20 percent, possibly lower. I know it was under half, I just don't know for sure how far. > Ah, I went itno this project execting it to fail, as the vast > majority of such things do. Mind you, it has lasted a HECK of a lot > longer than I expected, and progressed a lot farther than I exected as > well. I have already benefitted just from being associated with this project, and there's still a glimmer of hope that it can be seen through. But only a glimmer.= From hotmail.com!ralle33 Fri Jul 17 07:04:23 1998 Return-Path: Received: from hotmail.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0yxB7F-000fJGC; Fri, 17 Jul 98 07:04 PDT Received: (qmail 1597 invoked by uid 0); 17 Jul 1998 13:54:33 -0000 Message-ID: <19980717135433.1596.qmail@hotmail.com> Received: from 62.52.64.62 by www.hotmail.com with HTTP; Fri, 17 Jul 1998 06:54:33 PDT X-Originating-IP: [62.52.64.62] From: "Ralf Kreusel" To: ag-directors@krl.caltech.edu Subject: Project: von Neumann Content-Type: text/plain Date: Fri, 17 Jul 1998 06:54:33 PDT Hello, I would like to know when and where I can download this game in order to participate to your project. Are there any other projects with a learning system? Thanks for your help Ralf from Berlin/Germany Ralf Kreusel Emdener Strasse 37 D-10551 Berlin Ralle33@hotmail.com ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From hotmail.com!ralle33 Fri Jul 17 07:43:29 1998 Return-Path: Received: from hotmail.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0yxBjB-000fJNC; Fri, 17 Jul 98 07:43 PDT Received: (qmail 28884 invoked by uid 0); 17 Jul 1998 14:33:45 -0000 Message-ID: <19980717143345.28883.qmail@hotmail.com> Received: from 62.52.64.62 by www.hotmail.com with HTTP; Fri, 17 Jul 1998 07:33:44 PDT X-Originating-IP: [62.52.64.62] From: "Ralf Kreusel" To: ag-directors@krl.caltech.edu Subject: Project: von Neumann Content-Type: text/plain Date: Fri, 17 Jul 1998 07:33:44 PDT Hello, I would like to know when and where I can download this game in order to participate to your project. Are there any other projects with a learning system? Thanks for your help Ralf from Berlin/Germany Ralf Kreusel Emdener Strasse 37 D-10551 Berlin Ralle33@hotmail.com ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com