sttr-open Mailing List for The Resistance: Final Line (Page 3)
Status: Alpha
Brought to you by:
borg
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(7) |
Jul
(11) |
Aug
(5) |
Sep
(2) |
Oct
(4) |
Nov
(8) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(11) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(7) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Chris G. <chr...@po...> - 2001-07-06 12:49:01
|
I just got .str format working today. I did hope to publish the alpha today but a few bugs have been created due to the new object infrastructure which need fixing. Sunday? I'll probably hold a group conversation also when people have had time to view the new release. btw, the game and editor are now integrated. I suggest that you see if the editor is usable or not; if it isn't we can work to find another third party editor with a file format that I can program the editor to understand. Also, you might be interested that the editor can support multiple formats (currently .obj and .str) and can therefore act as its own convertor. The game also supports multiple formats, because of their integration, but I'd rather not use that feature. I could make a test map, or you could just go into data\galaxy\maps\fight_1.map and replace a cube.str with a test.str. I'll probably do what you suggest anyway. > -----Original Message----- > From: stt...@li... > [mailto:stt...@li...]On Behalf Of Gideon > Wormeester > Sent: 06 July 2001 12:36 > To: stt...@li... > Subject: [Sttr-open] New Alpha, when? > > > When is the new alpha ready for distribution, and the editor? Because a > conversionprogram would be to complex (I can't make, because of the > differences between C and Pascal) so every object has to be > recreated with > the new editor (shouldn't be to much work, just one object, a > cube). But I'd > like to make a STTR-version of my type9-shuttle and bird of prey > as soon as > possible. > > > Live Long And Prosper, > > Gideon > > ps. Chris, could you make some sort of a test-map, so that I can save new > objects with the filename test.str or something like that, then > run the game > with a special parameter and load the map with the new object to > test it in > the STTR 3D-world. > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > Sttr-open mailing list > Stt...@li... > http://lists.sourceforge.net/lists/listinfo/sttr-open > |
From: Gideon W. <wor...@ho...> - 2001-07-06 11:35:36
|
When is the new alpha ready for distribution, and the editor? Because a conversionprogram would be to complex (I can't make, because of the differences between C and Pascal) so every object has to be recreated with the new editor (shouldn't be to much work, just one object, a cube). But I'd like to make a STTR-version of my type9-shuttle and bird of prey as soon as possible. Live Long And Prosper, Gideon ps. Chris, could you make some sort of a test-map, so that I can save new objects with the filename test.str or something like that, then run the game with a special parameter and load the map with the new object to test it in the STTR 3D-world. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
From: Chris G. <chr...@po...> - 2001-07-04 13:14:21
|
Thanks to the kind support of the mp3lib creator, Sttr now uses mp3's for its sound (optional, but default sounds will be .mp3's). I've programmed two ways the game can use them: decoding in one go and decoding as they play. I'm also written a cool new sound API, which supports the following formats, without distinction: - wav - mp3 - cd audio - mid The API will cache the sounds, and they will be referred to by filename only (previously ugly ID mapping was involved, meaning filenames have to be hardcoded into the engine). This allows an event in 3D mode to play any of the previous formats. Map music can now be any of these formats, as the music entry in the map format just points to a filename. Sounds coded into the game are linked to an external .ini file which defines the relevant filenames. If a sound is to be looped then the first character of that sounds path must by a CAPITAL or a number (0-9). If an mp3 is to be fully decoded on loading then the file path must end .MP3 rather than .mp3. This stuff is a bit of a hack, but it works. NB: If we make a Linux port we must make all filepaths lowercase when the file is being loaded. You're probably wondering how you load a CD audio track: they have no filename. Simple! Just make the path <no>.cda, eg. 1.cda is track 1. These will always be set to loop. ----------------------------------- Chris Graham: CGS and Assimilation Software - http://browse.to/cgs - mailto:chr...@po... |
From: Chris G. <chr...@po...> - 2001-07-01 18:50:32
|
I'll create my own hidden-private chatroom when I logon. Then I have to specifically invite people: that's why I need the Yahoo ID's; To get invited you have to be logged into yahoo chat already, and something will then popup on your screen. > -----Original Message----- > From: stt...@li... > [mailto:stt...@li...]On Behalf Of Gideon > Wormeester > Sent: 01 July 2001 15:47 > To: stt...@li... > Subject: [Sttr-open] Chat, monday, but where? > > > Hi, > > Where do we need to go monday to chat. Chris said Yahoo!, but > there are many > Yahoo-chatboxes. So Chris, if you can reply to this one before monday 7pm > GMT, would be nice :-) > > Live Long And Prosper > > Gideon > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > Sttr-open mailing list > Stt...@li... > http://lists.sourceforge.net/lists/listinfo/sttr-open > |
From: Gideon W. <wor...@ho...> - 2001-07-01 14:47:08
|
Hi, Where do we need to go monday to chat. Chris said Yahoo!, but there are many Yahoo-chatboxes. So Chris, if you can reply to this one before monday 7pm GMT, would be nice :-) Live Long And Prosper Gideon _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
From: Chris G. <chr...@po...> - 2001-06-30 16:36:51
|
Actually we have two object formats already, and all the infrastructure for AI and so forth (has to be hardcoded into the game using object id's). > -----Original Message----- > From: stt...@li... > [mailto:stt...@li...]On Behalf Of Brandon > Siegel > Sent: 28 June 2001 21:56 > To: stt...@li... > Subject: [Sttr-open] Re: Map file-format > > > Do we have a format to create levels yet? If not, we could > include a bunch of subroutines in the actual program that read a > map format (for example: > > :MAP: > name="Test Map"; //Map name > width="300"; //Map width > height="500"; //Map height > start="150,150"; //Start at 150,150 > > :WALKWAY: > "150,150:155,152"; //Makes a 5x2 walkway > > :ALCOVE: > "149,150"; //Makes an alcove next to the walkway > > :DRONE: > "155,152"; //Places a drone on the walkway > > and so on.) Each time, for example, a drone entry is read, a > subroutine in the program that creates a model of a drone in a 3d > environment, adds collision detection, adds AI, and does > everything needed to create a drone in the game, is called and > the location is passed as a parameter. This seems like it would > modularise the levels and make them quick to make, when it comes > time to make all the levels. Unfortunately, we do not have > anything like ICARUS (used in Voytager: Elite Force) to script > in-game actions, so the plot may be difficult to visualise. Oh well... > > > > > ----------------------------------------------- > Runbox Mail Manager - www.runbox.com > Free online email application > > _______________________________________________ > Sttr-open mailing list > Stt...@li... > http://lists.sourceforge.net/lists/listinfo/sttr-open > |
From: Chris G. <chr...@po...> - 2001-06-30 16:36:50
|
Map files will take significantly less time being processed than object files, so I don't really care about their format. Also, they will always be loaded in one go at the start of a level [speed is irrelevant then, or at least less relevant], whilst objects may be dynamically loaded. I've nearly finished the new multiple-object-format infrastructure for sttr, and expect a new release of the game in about a week. Chris > -----Original Message----- > From: stt...@li... > [mailto:stt...@li...]On Behalf Of Gideon > Wormeester > Sent: 30 June 2001 11:59 > To: stt...@li... > Subject: [Sttr-open] Re: Sttr-open digest, Vol 1 #14 - 1 msg > > > (replying to Brandon Siegel) > > Yes well, that's nice, but it's script-based. It's inefficient. The > object-file-format once was text/script-based, but now it's a binary > fileformat and that's much better because the game doesn't have to parse > strings to read the file. > > I don't know the current mapformat for STTR, but I suggest a > binary-file-format, for better performance > > Live Long And Prosper > > Gideon > > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > Sttr-open mailing list > Stt...@li... > http://lists.sourceforge.net/lists/listinfo/sttr-open > |
From: Gideon W. <wor...@ho...> - 2001-06-30 10:58:53
|
(replying to Brandon Siegel) Yes well, that's nice, but it's script-based. It's inefficient. The object-file-format once was text/script-based, but now it's a binary fileformat and that's much better because the game doesn't have to parse strings to read the file. I don't know the current mapformat for STTR, but I suggest a binary-file-format, for better performance Live Long And Prosper Gideon _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
From: Brandon Siegel<tr...@im...> - 2001-06-28 20:59:06
|
Do we have a format to create levels yet? If not, we could include a bunch = of subroutines in the actual program that read a map format (for example: :MAP: name=3D"Test Map"; //Map name width=3D"300"; //Map width height=3D"500"; //Map height start=3D"150,150"; //Start at 150,150 :WALKWAY: "150,150:155,152"; //Makes a 5x2 walkway :ALCOVE: "149,150"; //Makes an alcove next to the walkway :DRONE: "155,152"; //Places a drone on the walkway and so on.) Each time, for example, a drone entry is read, a subroutine in = the program that creates a model of a drone in a 3d environment, adds colli= sion detection, adds AI, and does everything needed to create a drone in th= e game, is called and the location is passed as a parameter. This seems lik= e it would modularise the levels and make them quick to make, when it comes= time to make all the levels. Unfortunately, we do not have anything like I= CARUS (used in Voytager: Elite Force) to script in-game actions, so the plo= t may be difficult to visualise. Oh well... ----------------------------------------------- Runbox Mail Manager - www.runbox.com Free online email application |
From: Chris G. <chr...@po...> - 2001-06-27 09:10:03
|
I've sent this e-mail to the STTR mailing list and to everyone who has expressed interest in working on STTR. First: If you received this message twice, then you are on the mailing list. If you didn't... then please get on it, because all our important group mail will be going through it. Go to this URL to register: http://lists.sourceforge.net/lists/listinfo/sttr-open Send mail to: stt...@li... Second: The development should really be hotting up because I'm free from school now, and it is 12 weeks before I go to University (I may be free there to: I am doing a Computer Science course, which I probably know a lot of). Third: I'm planning a group chat on Monday at 7PM GMT. If you have Daylight saving time, remember to take that into account. The chat will be done at chat.yahoo.com. You need a yahoo ID to chat, I suggest you get one now. The room will be secret, so you all need to give me your yahoo ID's before Monday, and I can invite you when I open the room. I presume then you'll get a mail message saying go to ? URL, or similar. If anyone has a better way to chat, tell me, and I may give out a better game plan. Thanks ----------------------------------- Chris Graham: CGS and Assimilation Software - http://browse.to/cgs - mailto:chr...@po... |
From: Gideon W. <wor...@ho...> - 2001-06-25 19:27:56
|
Wow, that's a huge message. Anyway, Chris and I will be doing the col-detection-system. And I think I could make up a nice storyline. If someone (Chris?) could mail me the exact requirements for the story (such as, when it happens, what StarTrek-events happened and what didn't, where in the galaxy is Voyager at the time of the story, etc..) Live Long And Prosper Gideon >From: stt...@li... >Reply-To: stt...@li... >To: stt...@li... >Subject: Sttr-open digest, Vol 1 #11 - 1 msg >Date: Mon, 25 Jun 2001 12:15:10 -0700 > >Send Sttr-open mailing list submissions to > stt...@li... > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.sourceforge.net/lists/listinfo/sttr-open >or, via email, send a message with subject or body 'help' to > stt...@li... > >You can reach the person managing the list at > stt...@li... > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Sttr-open digest..." > > >Today's Topics: > > 1. (no subject) (Chris Graham) > >--__--__-- > >Message: 1 >From: "Chris Graham" <chr...@po...> >To: "Sttr-Open@Lists. Sourceforge. Net" <stt...@li...> >Date: Mon, 25 Jun 2001 15:31:43 +0100 >Subject: [Sttr-open] (no subject) >Reply-To: stt...@li... > >This is a multi-part message in MIME format. > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > charset="iso-8859-1" >Content-Transfer-Encoding: 7bit > >Hello everybody! > >I've updated the todo-lists quite a bit, so here they are. > >I'm going to try and organise a internet chat between everyone >interested in sttr in a week or so. Does anyone know a good >way to do this (yahoo?). > >----------------------------------- > >Chris Graham: CGS and Assimilation Software > - http://browse.to/cgs > - mailto:chr...@po... > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="sounds.txt" >Content-Transfer-Encoding: quoted-printable >Content-Disposition: attachment; > filename="sounds.txt" > >STTR: Comm-voices still to be made >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Aaarh, they're everywhere. > >We're abandoning ship > >30 wounded, 17 dead, on the Enterprise (or whichever ship is in = >question) > >------------------------------------- > > >If you can think of more, then please update this file and re-post it on = >the mailing list. > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="test.txt" >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; > filename="test.txt" > > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="todo.txt" >Content-Transfer-Encoding: quoted-printable >Content-Disposition: attachment; > filename="todo.txt" > >STTR: General Todo lists >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >This file says what is to be done for STTR, and what is assigned >to whom. It is intended to be updated be anybody working on STTR >and immediately redistributed on the mailing list. > >See todo-notes for relevant information on some of these tasks. > >This list is current to the latest version of STTR on Chris's >computer, and not the latest release alpha. I know CVS is a better >way to do this sort of stuff, but it is complex, and Chris can't go >on the net as often as would be required. > >------------------------------------- > > >(chris) Get working in Windows, Windows directory listing >(chris) .mp3 support, lower volume, better sound caching >(chris) Add Sam's new e-mailed sounds to game (+ a few more should be = >coming) >(chris, anyone) Fix crash bugs >(chris) New object format >Faster turning [don't know how!] >Joystick support >Re-port to linux > >(chris) Test/Debug/Finish phasers > - fix streaking > - make much, much faster > - texture problems > - positioning > - straight on > - as above but mouse can alter it > - auto-target > - definable start pos > - support other beam types > >3D > - (chris) Sprite clip bug > - (chris) Sprite collision bug > - Fix movement once and for all [movement eqns are wrong!] > - (chris) Fix texture bugs > - OpenGL? > - Rubble, Debree, Gore > - Curves/Spheres > >Flight Combat Mode > - (gidion, chris) Fix/Improve col detection > - involve back-face culling > - Improve clipping > - Ship AI, People AI > - Evasive maneuvers > - Circular backgrounds > >First Person Mode > - Enhance 3D engine a lot > - Pick ups > - A better test map > - Pushable entities > - First-person characters > - New weapons > - Lighting effects > >General stuff > - Make some editor base objects > - Maps and 3D-models > - Make some comm sounds > - Network support (can wait until sequel if no-one wants to do it) > >STTR Warp 2 (sequel) > - Better storyline/maps/engine > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="sfdtodo.txt" >Content-Transfer-Encoding: quoted-printable >Content-Disposition: attachment; > filename="sfdtodo.txt" > >STTR: To do on SFD >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Bolian Co-husbands > >Projectile weapons where bullet is teleported, with exographic targeting = >sensor > >Long Vulcan lifespans > >Trill rite to Bring up hosts personalities: rite of emergence, pocession > >Grid 315, Devore Imperium, 11 systems, 3 sectors. Intolerant of outsodes > >Vaadwaur, Turei, underspace > >Borg about 930 years old > >Kahless Warcry: "Today is a good day to die". > >Romulan Procouncil + used as a title > >Cardassian Optolithic data rod > >Dermal Regenerator > >Transwarp Hub > >------------------------------------- > > >If you can think of more, then please update this file and re-post it on = >the mailing list. > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="ob2.txt" >Content-Transfer-Encoding: quoted-printable >Content-Disposition: attachment; > filename="ob2.txt" > >/************************************************************\ >|* OBJECT (.STR) FILE-FORMAT *| >|* FOR STAR TREK: THE RESISTANCE *| >|* BY: GIDEON WORMEESTER *| >|* EXTENDED BY: CHRIS GRAHAM *| >\************************************************************/ > >/************************************************************\ >|* NOTE: THIS .OBJ-FILE-FORMAT ONLY SPECIFIES THE 3D-SPECS *| >|* OF AN OBJECT, FOR THE ENGINE. OTHER PARAMETERS, LIKE *| >|* NAME OR HEALTH ARE SPECIFIED ELSEWHERE *| >\************************************************************/ > >This binary .STR file format is the successor to the .ini style, text = >based >.OBJ file format. They were both written for Star Trek: The Resistance, >by members of Assimilation Software. > > pascal-type c(++)-type comments >*************************************************************************= >*************************************************** > <-- FILE HEADER --> >MAGIC string of 6 char[6] // "STTROB", to show it is an = >STTR Object file >VERSION byte unsigned short // To allow unforseen extensions = >in the future >FLAGS byte unsigned short // 8 bit flags to allow unforseen = >extensions in the future >TYPE word unsigned int // Using a word, we can use up to = >65536 different object-types, should be enough. >POLYGONS word unsigned int // 65536 polygons per object, far = >more than we'll ever need, but 256 won't be enough. >VERTICES word unsigned int // 65536, limiting the number of = >polygons but we've still got several thousands. > > <-- MAIN FILE --> >// This part should be present VERTICES times. >VERTEX.X real float >VERTEX.Y real float // X,Y and Z values are used to = >indicate the position of the vertex in the 3d world (duh) >VERTEX.Z real float > >// And this part should be present POLYGONS times >POLYGON.VERTICES byte unsigned int >POLYGON.TEXTURE word unsigned int // Texture ID for this polygon > // This part repeated POLYGONS.VERTICES times > POLYGON.VERTEX1 word unsigned int // First vertex > POLYGON.VERTEX2 word unsigned int // Second vertex > >ENDOFFILE word unsigned int // This doesn't do anything, but = >it's here to confirm a good file-ending. At the end of each object-file = >a word with value 12345 should be written. When reading the file, this = >last word can be used to check if the file isn't corrupt and that there = >are as many polygons and vertices as indicated. >*************************************************************************= >*************************************************** > >A word or unsigned int consists of 2 bytes, a dword 4 bytes and a byte = >is=20 >(surprise!) 1 byte. >The example on the website would look like this in the new file-format = >(off=20 >course, this isn't what an object-file should look like, but this makes = >it=20 >easier to comprehend): > >STTROB 1 0 0 6 8 (file-header) >-30 30 30 (vertex 0) >30 30 30 (vertex 1) >-30 30 -30 >30 30 -30 >-30 -30 30 >30 -30 30 >-30 -30 -30 >30 -30 -30 (vertex 7) >4 0 0 1 3 2 (poly 0, first vert.count, then texture, 4 times a = >vertex-ID) >4 0 1 0 4 5 (poly 1) >4 0 2 3 7 6 >4 0 6 7 5 4 >4 0 3 1 5 7 >4 0 0 2 6 4 (poly 5) >12345 > >the total file-size of this file would be: 178 bytes. > >All this stuff is loaded into the games internal class structure. > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="ob1.txt" >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; > filename="ob1.txt" > >STTR: Old object-definition-format (.obj) >========================================= > >This is a _very_ simple format and like all STTR formats it is >written around the .ini interface available from the Allegro >game library (ie. it is .ini file style) coupled with some >functions to write arrays into one of these files. > >All the info for STTR is kept in the data repository >(see web page, tech documentation). This includes textures, >objects, maps and sounds. > >------------------------------------- > > >Important simple integer entries: > - type = x Nothing 3D about this: it links object > geometry to object handling code. > Internally constants are assigned to > these numbers, eg. TYPE_BORGCUBE. > If anyone creates a new type, I'll assign > a type number. Different objects may > have the same type, and type info such > as health is defined in a separate file. > - polygons = x how many polygons the object uses > - vertices = x how many vertices the object uses > >------------------------------------- > > >Polygon entries: > >For the following, 0<=x<polygons > > - p_x_vertices = how many vertices there are in polygon x > - p_x_y = for the yth vertex of polygon x, what is the vertex id > - p_x_texture = a texture id > >------------------------------------- > > >Vertex entries: > >For the following, 0<=x<vertices > >I put what was previously the variable x as "x" to avoid confusion >with the 1st dimension, x. :-) > > - v_"x"_x = Position of vertex "x" in the x (1st) dimension > - v_"x"_y = Position of vertex "x" in the y (2nd) dimension > - v_"x"_z = Position of vertex "x" in the z (3rd) dimension > >------------------------------------- > > >NB's: > > - Vertices can of course be shared between polygons > - Polygons are 1-sided. To define which side is viewable, > you must choose the vertices in clockwise order from that > side. > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="libs.txt" >Content-Transfer-Encoding: 7bit >Content-Disposition: attachment; > filename="libs.txt" > >STTR: Libraries/Dependencies used >================================= > >This file isn't really up-to-date with any specific >releases. Things here might only be planned for use >and the Linux version is currently broken. > >STTR uses: > - Allegro WIP http://www.allegro.cc > - LibZ > - LibPNG > - LoadPNG > - MP3Lib > >For the Windows version, DirectX is required. > >For the Linux version, X Window or SVGA Lib is required. >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="wwwtodo.txt" >Content-Transfer-Encoding: quoted-printable >Content-Disposition: attachment; > filename="wwwtodo.txt" > >STTR: Stuff for website >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >The website is currently being redesigned, so I'm building up a list of = >things to do when the new design is finished, >There is a chance that nothing has been done on the site yet, and all = >these updates will be done. > >To do on website >---------------- > >Remove "Project Information": "Being Done" section >Remote "Design": "Sounds" section >Update todo lists so they simply are copies of mailing list ones >Update team page >Put libs onto download page >Much more in tech manual, including new .txt files >Mailing list info on site >Info on endgame in "Borg Episodes" >Update treklink webring > >To add to changes list >---------------------- > >Perspective corrected drawing >Editor: Vertices as polygons >Now game/ed/setup in one .exe >Tidied source code >Reduced lib demand >Much smaller >Tidier directory tree >Fixed a few memory gobbles >Tweaked bailing out >Better error reporting >More tolerant of missing sounds, music etc >More portable (draws on Allegro more) >New/Tweaked sounds >Flight combat voices (Sam, Chris) >Fixed bug in insert menu (editor) >Editor: To avoid confusion, insert object menu is never called import = >object >Lists can now be made out of directory entries >New .str object format implemented, + easy support for new formats (lots = >of work for this one) > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="collision-detection.txt" >Content-Transfer-Encoding: quoted-printable >Content-Disposition: attachment; > filename="collision-detection.txt" > >/************************************************************\ >|* COLLISION-DETECTION (.CLD) FILE-FORMAT *| >|* FOR STAR TREK: THE RESISTANCE *| >|* BY: GIDEON WORMEESTER *| >\************************************************************/ > >/************************************************************\ >|* NOTE: THIS .CLD-FILE-FORMAT SPECIFIES COLLISION-DETECTION*| >|* DATA OF AN OBJECT. EACH .STR-FILE SHOULD HAVE AN *| >|* .CLD-FILE WITH THE SAME NAME. FOR EXAMPLE: CUBE.STR AND *| >|* CUBE.CLD. *| >\************************************************************/ > >/************************************************************\ >|* INTRODUCTION TO THE STTR COLLISION-DETECTION-SYSTEM *| >\************************************************************/ > >STTR collision-detection (CD) is based on boxes. An object consists of=20 >multiple boxes. The basic idea behind >the STTR CD-system is that if a box of one object should enter a box of=20 >another one, a collision takes place. >The most simple method of creating a box-structure is defining a box = >just=20 >around the object. This works for a >cube, but when a box-structure has to be defined around a Bird of Prey, = >a=20 >single box would be very inaccurate. >(Check attached example-image). A small shuttle could try to fly between = >the=20 >birds wings, but the CD-system >would count that as a collision, while it isn't one. To prevent this = >from=20 >happening, the CD-S makes it possible >to define multiple boxes around different parts of the object. In the=20 >BOP-example, one around the foreward section, >one around the smaller middle-section, one around the aft-section, and a = >few=20 >around the wings. Using this >multiple-box-structure the CD-system can simulate the shapes of the = >object=20 >more accurately. > >/************************************************************\ >|* FILE-FORMAT FOR .CLD-FILES *| >\************************************************************/ > > pascal-type c(++)-type comments > <-- FILE HEADER --> >MAGIC char[6] char[6] // Should be 'STTRCD' to=20 >identify the file as collision-detection file >COLLISION_BOXES byte unsigned short // Number of=20 >collision-detection-boxes in the box-structure of the object. > > <-- MAIN FILE --> >// This should be repeated COLLISION_BOXES times: >LEFTFRONTBOTTOM.X real float // Two points are enough = >to=20 >define the entire box. >LEFTFRONTBOTTOM.Y real float // The following should = >be=20 >true for every C-BOX: >LEFTFRONTBOTTOM.Z real float // (LFB.X < RBT.X) && = >(LFB.Y=20 >< RBT.Y) && (LFB.Z < RBT.Z) >RIGHTBACKTOP.X real float // where LFB stands for=20 >LEFTFRONTBOTTOM >RIGHTBACKTOP.Y real float // and RBT for = >RIGHTBACKTOP >RIGHTBACKTOP.Z real float // There's still a = >problem to=20 >be solved, a c++-float is 4 bytes, a pascal-real is 6. > >ENDOFFILE word unsigned int // This 'magical' = >constant=20 >should always be 12345, so the game can check if the file isn't corrupt. > >/************************************************************\ >|* EXAMPLES *| >\************************************************************/ > >Cube: (like the one on the website, and in the .str-specs) > >STTRCD 1 (file-header) >-30 -30 -30 30 30 30 (First (and only) C-Box) >12345 >(Note: the file-format is binary, not textual as it is shown in the = >above=20 >example) > >Stairs: (for the 1st-person mode?) > _ > _| | > _| | >_| | >|_______| (side y/z) > >_________ >|_______| >|_______| >|_______| >|_______| (front x/z) (and top x/y, because that one looks exactly the = >same) > >STTRCD 4 (file-header, every layer contains 1 c-box, giving a total of = >4) >0 0 0 40 40 10 (1st c-box, bottom layer) >0 10 10 40 40 20 (2nd c-box) >0 20 20 40 40 30 (3rd c-box) >0 30 30 40 40 40 (4rd c-box) >12345 > >/************************************************************\ >|* MISC. *| >\************************************************************/ > >I've added a example Pascal-program that asks the coords of two c-boxes = >and=20 >checks wether they collide. >The source code is also attached. This CD-system can be a little bit=20 >confusing, so don't hesitate >to ask me some questions. Just send an email to the mailing-list with = >the=20 >subject 'question for Gideon' >or something like that. > >------=_NextPart_000_0005_01C0FD8B.F004C5E0 >Content-Type: text/plain; > name="todo-notes.txt" >Content-Transfer-Encoding: quoted-printable >Content-Disposition: attachment; > filename="todo-notes.txt" > >STTR: Notes for developers >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D > >How the project is organised > - Generally people will be working in isolated functions, and should = >e-mail Chris the changed files, with notes on what functions have had = >major work done on, and any other changes made > - I know this isn't a very good system, but I can't think of a better = >one without keeping going on the net, or locking people out of files for = >excessive amounts of time > - The todo list is distributed on the mailing list primarily, with info = >on who is doing what > - The todo-commsound list is also distributed on the mailing list > >------------------------------------- > > >MP3 Support > - A library has been written which works with Allegro and allows us to = >use .mp3's as a plugin replacement for .wav > - I will put this support into the game soon, but I'm a bit concerned = >about speed > - Alternatively, I might make the game save decompressed versions to = >disc at first run > >Music, etc > - It is possible that we might have a for-order version of the game, = >with loads of music, etc > - We could do with someone with advanced musical knowledge to remake = >trek music from episodes without the voices, or compose from scratch > - Music is not a priority: if it comes to the worst, we can always = >simply play the users personal audio CD tracks instead > >Linux Support > - Needs updating (hasn't been compiled for ages) > - Automated installer to get everything working on a clean system > - Must work as well as DOS/Windows versions > - I (Chris) don't have Linux installed at the moment, so can't work = >with it: I will be using Linux as my primary system next academic year > >Open GL > - A consideration, but would require scrapping DOS version > - AllegGL allows Allegro to work alongside it > - Does it provide useful features? > >Phasers > - This is taking a long time for me to do > - The phaser beams need trimming if they go behind the camera. This is = >complex > - Another difficulty is properly creating the beam out of a polygon and = >two sprites, and making it look right > >First Person Mode > - This was last worked on before Z-buffering was back working again. = >Thus it couldn't be properly done (obscuring is more important when = >surrounded by lots of polygons). > - I (Chris) intend to put an awful lot of effort into this over the = >next few months > >Network support > - I was intending this to be written for a sequel to STTR, but if = >someone wants to do it, they can > - DOS support is problamatic: I suggest only Supporting Linux and = >Windows > - I suggest it should be coded using BSD-Sockets and Winsock (almost = >the same) > - I have some experience with sockets if help is required (my VTL game) > >Artificial intelligence > - I (Chris) was intending to write this using VTL (my other game) code. = >This might not really be appropriate though, so someone else can write = >it from scratch if they like > - I (Chris) suggest creating a list of priorities, including defence = >and attack functions. This would be linked with a number of sensors for = >each priority > - Then the commands to deal with the highest priority can be placed on = >a stack and executed as quickly as possible > - Path finding for AI: this is hard. I (Chris) suggest a simplified map = >is maintained to work against (a "cognitive model") > >Storyline > - Voyager is finished. The games storyline is based around Voyager = >coming home: I (Chris) think it should stay like this; lets just call it = >a different timeline (required anyway) > - A storyline will be required for a sequel though (if we make one); = >any suggestions? (make one if you like) > >Circular backgrounds > - I (Chris) don't really know how to do this. Clearly we need some way = >of wrapping a number of flat bitmaps onto a sphere > >Joystick support > - This can be done through Allegro, and is something any programmer = >could implement if they like > >Lighting effects > - This can also be done through Allegro, but will be difficult in 8bit = >mode. Perhaps 8 bit mode should be scrapped > >Collision detection > - Ouch! This is very hard in 3D. Maybe some sort of genius will rewrite = >my (Chris's) code so it is fast and accurate > - A rewrite/major improvement will definitely be required for First = >person mode > - Ammedment: Gideon has designed a new collision detection system to be = >implemented > >3D models > - These can be made through the editor, but I also plan to support at = >least one third party object format in the game. Anyone want to write a = >parser? > - Other file formats tend to be very different from ours. Textures = >might be a problem, as they are separate to the objects themselves > >Comm sounds > - The game will mix sound files together during battle scenes on a comm = >frequency, like at the start of "First Contact" > - Many different voices are needed for this to work: tell you're = >friends :-) > - Refer to sounds.txt for ones to be made > - Go on, be famous! > >------=_NextPart_000_0005_01C0FD8B.F004C5E0-- > > > > >--__--__-- > >_______________________________________________ >Sttr-open mailing list >Stt...@li... >http://lists.sourceforge.net/lists/listinfo/sttr-open > > >End of Sttr-open Digest _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
From: Chris G. <chr...@po...> - 2001-06-25 14:31:55
|
Hello everybody! I've updated the todo-lists quite a bit, so here they are. I'm going to try and organise a internet chat between everyone interested in sttr in a week or so. Does anyone know a good way to do this (yahoo?). ----------------------------------- Chris Graham: CGS and Assimilation Software - http://browse.to/cgs - mailto:chr...@po... |
From: Chris G. <chr...@po...> - 2001-05-22 20:15:47
|
> Oops, didn't think of rotating when I designed the specs. There are two > solutions: > 1) A collision-box has to be defined using 6 vertices instead of 2 > 2) The collision-box-coords should be relative to the base (0,0,0) of an > object. This way 2 points are still enough (I think) We should use 2), but the points should be relative to the object origin, as it is with the object itself. I don't see what you were defining points relative to before though, but as far as I can see your format is still perfect. I only talked about rotation because I thought we should all know about what the games collision detection code should consist of. > > by the way, Chris, my name is Gideon, not Gidian > Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon Gideon !! I'll update stuff whenever I've found I've mispelled your name. Sorry about that. I think there is an English name Gidian, which is why I'm confused. |
From: Gideon W. <wor...@ho...> - 2001-05-22 07:03:03
|
Oops, didn't think of rotating when I designed the specs. There are two solutions: 1) A collision-box has to be defined using 6 vertices instead of 2 2) The collision-box-coords should be relative to the base (0,0,0) of an object. This way 2 points are still enough (I think) by the way, Chris, my name is Gideon, not Gidian _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
From: Chris G. <chr...@po...> - 2001-05-21 14:06:55
|
(Oh dear. I just posted this on the Allegro mailing list by mistake!) I checked over Gidians specs and think they are good. Now, maybe we should - write a program to reasonably autogenerate collision detection files .ini style files - write a program to convert between .ini style and binary style collision detection files I want a .ini style type because I don't fancy making collision detection info in a hex editor! I won't be coding for a while, because I have exams. After that I won't have anything much better to do. NB: The game will require these collision boxes to be rotated whilst testing for a collision (objects can tilt). ----------------------------------- Chris Graham: CGS and Assimilation Software - http://browse.to/cgs - mailto:chr...@po... ----------------------------------- Chris Graham: CGS and Assimilation Software - http://browse.to/cgs - mailto:chr...@po... |
From: Chris G. <chr...@po...> - 2001-05-19 18:39:08
|
Nothing went wrong for me. I presume you got a corrupt file: I didn't. It must have got corrupted because of a bad connection, or similar. > -----Original Message----- > From: stt...@li... > [mailto:stt...@li...]On Behalf Of Gideon > Wormeester > Sent: 18 May 2001 20:39 > To: stt...@li... > Subject: [Sttr-open] Col-detect > > > Whoops, something went a little bit wrong with attaching binary-files > (images, zips) on sourceforge-lists. I'll upload it to a website one of > these days, so you can download it from there. > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > Sttr-open mailing list > Stt...@li... > http://lists.sourceforge.net/lists/listinfo/sttr-open > |
From: Gideon W. <wor...@ho...> - 2001-05-18 19:39:01
|
Whoops, something went a little bit wrong with attaching binary-files (images, zips) on sourceforge-lists. I'll upload it to a website one of these days, so you can download it from there. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
From: Chris G. <chr...@po...> - 2001-05-18 09:23:35
|
You can find us at "http://sttr.sf.net" due to sourceforge buying the sf.net domain. ----------------------------------- Chris Graham: CGS and Assimilation Software - http://browse.to/cgs - mailto:chr...@po... |
From: Chris G. <chr...@po...> - 2001-05-18 08:53:36
|
I'll check this out. > -----Original Message----- > From: stt...@li... > [mailto:stt...@li...]On Behalf Of Gideon > Wormeester > Sent: 15 May 2001 19:52 > To: stt...@li... > Subject: [Sttr-open] yet another problem > > > hi > > there's another problem with the obj-specs. A float in C(++) is 4 bytes, > a real (as Pascal-people call the floating-point-thingie) is 6 > bytes. Does > C(++) has some sort of extended float to fix this. > > Annoying isn't it, working with to seperate languages. I hate C, but it's > necessary for the performance of the game (although Delphi can > produce some > rather rapid code, but reprogramming the entire game into > Delphi-Pascal is a > devestating task :-( > > Gideon > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > Sttr-open mailing list > Stt...@li... > http://lists.sourceforge.net/lists/listinfo/sttr-open > |
From: Chris G. <chr...@po...> - 2001-05-18 08:53:36
|
Good, thanks. This is an interesting approach which I've never seen, usually the collision detection stuff is taken straight from the geometry. I'll read it over. I'm still working on loading/saving the new objects: the code is written but I haven't gotten it working yet. A lot has had to be changed, including integrating the game and editor loading functions, and providing a framework for multiple object loading handlers. > -----Original Message----- > From: stt...@li... > [mailto:stt...@li...]On Behalf Of Gideon > Wormeester > Sent: 16 May 2001 20:59 > To: stt...@li... > Subject: [Sttr-open] Collision detection > > > Hi everyone, > > I read the todo-list and I've designed a new > collision-detection-system for > the game. I didn't check the old one, because I don't know what > file it is > in :-( I've attached everything on the new col.-det.-system, so > just check > it and see wether you like it. > > Greetz, > > Gideon > > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > |
From: Gideon W. <wor...@ho...> - 2001-05-16 19:59:14
|
Hi everyone, I read the todo-list and I've designed a new collision-detection-system for the game. I didn't check the old one, because I don't know what file it is in :-( I've attached everything on the new col.-det.-system, so just check it and see wether you like it. Greetz, Gideon _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
From: Gideon W. <wor...@ho...> - 2001-05-15 18:52:24
|
hi there's another problem with the obj-specs. A float in C(++) is 4 bytes, a real (as Pascal-people call the floating-point-thingie) is 6 bytes. Does C(++) has some sort of extended float to fix this. Annoying isn't it, working with to seperate languages. I hate C, but it's necessary for the performance of the game (although Delphi can produce some rather rapid code, but reprogramming the entire game into Delphi-Pascal is a devestating task :-( Gideon _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
From: Chris G. <chr...@po...> - 2001-05-14 17:02:01
|
Here are a few files which need spreading. ----------------------------------- Chris Graham: CGS and Assimilation Software - http://browse.to/cgs - mailto:chr...@po... |
From: Chris G. <chr...@po...> - 2001-05-13 12:37:34
|
Well I agree. I remember now that Pascal actually does it better than C (in my opinion) by holding the length in the first byte. I've almost finished implementing the format. Also, I changed it so there are also "unsigned int" for no's of vtx's in a polygon. It's just easier to use the same types. It's annoying: type lengths aren't constant. I'm saying an int is 2 bytes, a float is 4 bytes and a short is one byte. Maybe more memory will be allocated, but I don't care :-) As long as the correct info is read and written to our object files then that's fine with me. > -----Original Message----- > From: stt...@li... > [mailto:stt...@li...]On Behalf Of Gideon > Wormeester > Sent: 12 May 2001 15:53 > To: stt...@li... > Subject: [Sttr-open] obj-specs > > > Hi, > > I think we've got a little problem with the new version of the > .STR-format > you made. The problem is that strings are handled differently by > Pascal en > C(++). I think the MAGIC-variable/constant should be an array of > 6 chars at > all times to ensure cross-compiler compatibility. > > Everyone (involved in engine-programming, object-editing etc..) agrees? > > Greetz, > > Gideon > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > Sttr-open mailing list > Stt...@li... > http://lists.sourceforge.net/lists/listinfo/sttr-open > |
From: Gideon W. <wor...@ho...> - 2001-05-12 14:53:15
|
Hi, I think we've got a little problem with the new version of the .STR-format you made. The problem is that strings are handled differently by Pascal en C(++). I think the MAGIC-variable/constant should be an array of 6 chars at all times to ensure cross-compiler compatibility. Everyone (involved in engine-programming, object-editing etc..) agrees? Greetz, Gideon _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |