sc2-devel — For developers

Re: [Sc2-devel] Compiling under linux - automake pack

[Mudrony <mu...@in...>]

Here is a patch with my changes.
The patch was made a clean CVS tree processed and patched by Serge van
Boom's script/patch. This means that the files are moved, and the upcase
filenames are fixed.

Note that I jsut posted an another patch that tries to move files
itself. The message was large enough to be held for approval. That
message can be disregarded, this patch is much better.

This patch contains all the small, quick, dirty but efficient changes i
made to let the source compile. I post this patch so people can review
my changes and can come up with better soultions.

I just commented out the dos.h and io.h #includes, and I had to comment
all the calls for functions defined there. Fortunately this means only a
few calls, and they seem to be simple file attribute checks that should
be straightforward to port. Chris: try to use only stdio..

I added some conditionals to solve some those declaration conflicts,
and sometime even altered declarations or calls. The original is usually
left there commented.

When using CVS there is no reason to comment everythng and keep lengthy
history inside the sources since CVS does that much better. There is no
need to write names at all (so "Added by Chris" style comments are not
good). Except maybe some comments made above the code, wich may have a
name prepended. (Like: "Chris: Don't try this at home" :)

Someone might ask why I moved files, and why I added the those dummy.c
files:
- The race specific code found in sc2.code seems to belong to the ships,
  I gues they (ie the habit of putting them into sc2code) are leftovers
  from SC1. If planets/ and comm/ can have their subdirs then ships
  should have too. This inproves consistency a lot.
- paul from planets has to be removed for similar reasons.
  Source should be structured on clear conceptual reasons, so when
  a large enough group of sources has a clear distinctive group.
  Seeing your name in the path is not such a reason, even if admire
  paul's name a lot :) This is code not a family photo album :)
- For the same reason there should not be an sc2code subdir, and
  SDL_wrapper should be under the graphics subsystem, not at the top..
  Also the one file subdirs could be removed, and the dirs could be more
  respect to future modularization. And getting rod of the DOS 8.3 names
  in favor of more readable/descriptive names would be nice too. 
  These would require altering the whole thing, its not difficult, but
  it would be a patchning nightmare, and CVS would be even worse.
- My automake files build subdirs as static libs (as .a archive files)
  Automake does not seem to like libs that only contain code from other
  libs, it inssist on having at least one real source file, so I added
  the dummy.c files. If we want, we can be turn these into something
  more useful later.

Only thing new compared to my pack release that it builds test.c as a
separate sndtest executable.

This patch contains the most recent version of the Makefile.am files,
but does not contain the other automake/autoconf files.

[Sc2-devel] a dirty but complete patch of my changes

[Mudrony <mu...@in...>]

I didn't mentioned all the changes I made in the last mail, because
there was too many of them for me to remeber. I had to tweak includes
and comment out lines and then uncoment them when i found a better
solution :)

This patch was produced against a clean CVS tree, and it will try to
move files, and will leave empty directories. The CVS subdirs are not
touched.

I include this patch so people can review my changes and can sort out
the unnecessary ones. I hope Serge van den Boom can use this to produce
a better script, since the set of mv commands and a patch made against
an mv-ed source tree is much cleaner (and smaller).

gunzip the patch next to src/ and apply with:

patch -p0 -imudry.patch

I usually do not use diff dierctly becasue CVS takes care of it for me,
so I hope the patch is OK..

Re: [Sc2-devel] Compiling under linux - automake pack

[Serge v. d. B. <sv...@st...>]

Hi,

I've made a few scripts to automatically fix just about all
the problems Karl and Mudrony mentioned, from a clean CVS tree.
They should be suitable for reuse in future situations.


Greetings,

Serge

[Sc2-devel] Compiling under linux - automake pack

[Mudrony <mu...@in...>]

As I promised I did an "autoconfiscated" makefile using all the
autotools. This pack adds various files that are standard for
opensource/GNU projects. The autoconf file is pretty sophisticated.

It will add libtool and gettext support, wich is not required yet since
the curernt code does not make use of it, but I strongly suggest that..
The autogen.sh will run the tools that produce the generated files,
and will inject their stuff into top dist dir.

I even wrote a small intro (README.ac) for those that aren't familiar
with autotools. It also contains important details.

With numerous modifications I managed to compile the sources.
Some of these touches are detailed in README.ac, the others are
fixes for decalartion conflicts, and such. Some files inclode io.h
wich is not present on Linux. Some even include dos.h and windows.h..
I commented out their calls (mostly _setmode() with O_TEXT), to let the
compile proceed, but of course it will break the result. I even moved
some source files.

I will try to make a patch or to commit to CVS if Chris lets me to..

I already put a LOT work into this (12.39 hours!), and while
automake/autoconf makes life a bit complex the resulting flexibility
well worth the price. It's much sophisticated than Karl's Makefile
(Karl's modifications helped a lot)

This is a "beta version" of this automake pack, meaning that only one
person (Meep-Eep on #sc2) tested it (and found numerous small typos).

A few things certainly need tweaking, so take care when using it.
However it's already quite mature.. (it works fine for me :)

The tarball will unpack into its own dir to avoid trashing your distdir,
but all of its contents meant to reside in the top distdir
(the one that has src/, util/ and content/).

[Sc2-devel] Replacing graphics in SC2

[Nick B. <nic...@ma...>]

Are there any plans to replace any of the graphics in the new revamp
sc2? Interface or the like?

-Nick
_______________________________________________________________
 http://www.webmail.co.za the South-African free email service

Re: [sc2-devel] windows compilation

[Michael C. M. <mcm...@st...>]

On Sat, 17 Aug 2002, Alon Tirosh wrote:

> ok. we need to figure something out. Some of the people dev'ing for
> windows will be doing it in VS, and some people want to use ming. this
> can cause problems. personally i like to use VS because it gives me a
> better Debugger and i can look at the asm and tune the code better. this
> is just me. however, if we dev under two diff compilers, while both
> final products will work, we can have cross development issues. so. what
> to do?

There are two major cross-development issues that I know of.

(1) Build control.  This actually isn't that much of a problem, as long as
    we don't commit changes to the VC++ build files after the initial
    commit.  Given that locations of libraries and such are likely to
    change anyway, we'll all need our own makefiles/project
    files/whatever.  (That said, I now have a functioning .dsp for VC++6.0
    that compiles StarCon2Debug.exe.)
(2) Standards shift.  VC++6 doesn't fit the final ANSI standard for C++.
    The only place this is likely to bite us for portability is with loops
    defined like so:

    for(int i = 0; i < 17; i++) {
        /* Do stuff... */
    }

    Under VC++6, i continues to exist outside of the loop.  Under gcc, i
    goes out of scope when the loop ends.  I'm given to understand that at
    the time VC++ was correctly implementing a bad standard, which was
    later changed in the final ANSI standard for C++.

    Since that wasn't legal C, I don't think, when the original code was
    written, this is unlikely to be a problem except for code we add.  To
    port across compilers, either declare i outside of the loop (to make
    it stay), or surround the loop with braces, like so:

    {for(int i = 0; i M 17; i++) {
        // Do stuff
    }}

    This will make i become undeclared when the loop ends.

    People in the group I've been working with supported a vast library
    system that played nicely with both VC++ and gcc without having to do
    much to the sources, largely via this trick.

--Michael

[Sc2-devel] =?utf-8?B?UkU6IFtTYzItZGV2ZWxdIFRoZSBwcm9jZXNzIGJlZ2lucw==?=

[<ti...@pi...>]

It compiles and links fine using VC7 with SDL, SDL_image, SDL_mixer and
smpeg for win32.
When running it fails on InitResourceSystem() called inside LoadKernel(), as
starcon.pkg isn't in the content directory.
 
I've looked through the code and it seems Chris has done most of the hard
work in getting the code to compile and seperating out the 3DO specific
calls into SDL_wrapper.c. 
So I'm sure he'll have a good plan on what to do next and how to get the
resource system going again.
There is a lot of strange prototyping going on, which is all set up in
compiler.h in the sc2code\libs directory. Most of it looks redundant and can
be cleaned up with a perl script.
The proposed system of assigments seems logical, as if we're just working on
a wrapper and touching the original code as little as possible just to get
things going then Chris will really be the only one who's got the big
picture, and actually knows what the missing 3DO call do.
 
Cheers,
--tim--
 

-----Original Message-----
From: Chris Nelson [mailto:ch...@to...]
Sent: 16 August 2002 23:52
To: sc2-devel
Subject: [Sc2-devel] The process begins


Hello, everyone. 

Today, the source code have been posted to cvs.sc2.sourceforge.net, the
media is currently being uploaded (we'll see whether sourceforge gives us
the ~500 megs of storage space we need), and the open development phase of
the re-release of The Ur-Quan Masters begins. 

There are many development models we could use. To date, I've been the only
one making changes to the code itself (along with Fred), and have been
utilizing your abilities by giving detailed coding assignments. These
assignments allow me to offload problems that are more generally solvable,
so I can work on the problems that require a better understanding of the sc2
sourcecode itself. Thus, everyone works on the tasks that they are best
suited for. This has worked very well, and I think it's a pretty efficient
way to get things done. 

There are other models. I could, for example, open up the CVS repository,
and allow anybody to directly make changes to code and media. Although this
allows for a faster theoretical maximum development speed, it also
introduces the possibility of more bugs, and a somewhat more chaotic
atmosphere. This might be better suited for other projects that would like
to branch off, after we hit v1.0... 

If anyone disagrees, or wants to offer a different model, please post to the
list. 

Also, we have 32(!) people as far, on this list. To ensure that this list
doesn't generate too much traffic, I would encourage people to limit their
posts to the primary topic: development. We also have a channel on
irc.openprojects.net: #sc2. If you're working on an assignment, having a
presence in this channel would be a good idea, so you can collaborate with
other people who might be working on the same thing. The channel also is a
better place to just chat about the project, in general, without flooding
peoples inboxen. 

The first assignment is for everyone to download the project (all 500 megs),
and verify that it compiles + runs, if you're running some flavor of
windows. You'll need some libraries, specifically SDL, SDL_image, and
SDL_mixer. These can be obtained at libsdl.org... 

For those of us who'd rather work in Linux, our first job is to get the code
to compile there. This is probably one of the next things I'll be working
on. 

So over the weekend, feel free to examine the code, or try to make it work
under Linux (document your changes!). I'll be unavailable this weekend, and
will start giving assignments sometime next week. 

Enjoy! 

-Chris 

[Sc2-devel] updated Makefile

[Karl B. <ka...@gm...>]

Hi!

I've uploaded a new version of the makefile. Please report any 
problems/suggestions.

Changes:

- check for SDL version
- check for OpenGL
- including GL libs
- removed test.c from target

http://www.linux-games.com/make.tar.gz

Bye,

-- Karl

Re: [Sc2-devel] SDL and OpenGL

[<ze...@rp...>]

SSBqdXN0IGdvdCBpdCB0byB0b3RhbGx5IGNvbXBpbGUgYW5kIHJ1biBvbiB3
aW5kb3dzIGluIGN5Z3dpbiEJSSdsbCBjaGVjawppZiB0aGlzIHdvcmtzIGxh
dGVyIGluIGxpbnV4LiAgQW55d2F5LCBJdCBnZXRzIHRocm91Z2ggYWxsIG9m
IHRoZSBTREwgaW5pdApzdHVmZiwgYnV0IGZhaWxzIGF0IExvYWRLZXJuZWws
IHdpdGggIktlcm5lbCBmYWlsZWQgdG8gbG9hZCEiIGVycm9yCm1lc3NhZ2Uu
ICBhbnl3YXksIGl0IGNvbXBpbGVzLglUaGluZ3MgSSBoYWQgdG8gZG8gdG8g
Z2V0IGl0IHRvIGNvbXBpbGU6Cg0KLXN0YXJ0ZWQgd2l0aCBrYXJsJ3MgY29u
ZmlnDQotcmVtb3ZlZCB0ZXN0LmMgZnJvbSBtYWtlZmlsZSwgYWRkZWQgbGli
cy9yZXNvdXJjZS9kaXJlY3QuYyAoYWZ0ZXIKbG93ZXJjYXNpbmcpDQotY29t
ZW50ZWQgb3V0IHZhcmlvdXMgR0xPQkFMX1BST0MgZGlyZWN0aXZlcyBpbiB0
aGUgbGlicyBoZWFkZXIgZmlsZXMgdGhhdAp3ZXJlIGNvbmZsaWN0aW5nIHdp
dGggdGhlIGxpYnMgYyBmaWxlcy4gIEkgc3RpbGwgZG9uJ3Qga25vdyB3aGF0
CkdMT0JBTF9QUk9DIGFjdHVhbGx5IGRvZXMsIGJ1dCBJIGJldCBpdCBpc24n
dCBuZWVkZWQuDQotZml4ZWQgYSBidWcgaW4gcGxhbmV0cy9zY2FuLmMgKG1l
bnRpb25lZCBpbiBsYXN0IHBvc3QpDQotQWRkZWQgLWxHTCB0byBjb21tYW5k
IGxpbmUgcGFyYW1ldGVycyBpbiBtYWtlZmlsZQ0KDQpBdHRhY2hlZCBpcyBh
IGRpZmYgZmlsZSBnZW5lcmF0ZWQgZnJvbSB0aGUgY3ZzIHNvdXJjZXMgYW5k
IG15IGNoYW5nZXMuDQoNClN0aWxsIGxvdHMgb2YgY29tcGlsZXIgd2Fybmlu
Z3MsIGFuZCBpdCBvYnZpb3VzbHkgZG9lc250IHRvdGFsbHkgd29yay4NCgoK
Cg==

Re: [Sc2-devel] SDL and OpenGL

[<ze...@rp...>]

I agree with eric.  I checked the code, and as far as I can tell, no glut
functions are used at all.  SDL basically replaces GLUT and GLX.  Why a
windowing toolkit has a generate teapot function is a different matter :P. 
Also, to Karl, make sure you change the makefile to link with Opengl. 
Opengl is DEFINITELY used.  Uhh... random bug:
line 151 of planets/scan.c reads: 
wstrcpy (buf, "%s", GAME_STRING (SCAN_STRING_BASE + 4 + 51));
but that obviously doesn't work, it should be 
wsprintf (buf, "%s", GAME_STRING (SCAN_STRING_BASE + 4 + 51));

After fixing that and a fwe things with duplicate references, I got it to
go past the compile phase in cygwin!  Of course, it died in linker, but eh.
 Other stuff: you shouldnt link both test.c and the sdl_wrapper.c, as both
include SDL main functions.  test.c is a seperate application.	I had
trouble with some of the gfx functions in libs.  They way they are, it said
they were declared twice in incompatible ways, but when I deleted one of
them, it can't find the symbol.  Specifically GetFrameHot, GetFrameRect and
SetFrameHot.  I don't understand the code, cause its full of 3d0 macros. 
Uh, that's about it for now.

[Sc2-devel] SDL and OpenGL

[Eric W. <ewi...@ya...>]

Hi, just a quick suggestion on incorporating OpenGL in
an SDL project...

Since you are using OpenGL with SDL, you probably
don't need to include GLUT (<GL/glut.h>). Glut is
another cross platform library that comes with a lot
of stuff which is redundant to the SDL (Window
manager, event callbacks, mouse/joystick support). I
do not believe these features will cooperate with SDL.
I think only the shape drawing features
(glutSolidTeapot, etc) will work. 

What you probably want to include is <GL/glu.h> and
<GL/gl.h>. However, note that calling these is not
necessarily cross platform because the directory paths
have not been standardized. (MacOSX calls it OpenGL/)
Also, Windows requires <windows.h> for gl.h for some
really bizarre reason.

To get around this, SDL provides a nice interface for
OpenGL which I believe is the preferred method. Do a
#include "SDL_opengl.h" and it will include both gl.h
and glu.h for you.

Cheers,
Eric



__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Re: [sc2-devel] windows compilation

[<ze...@rp...>]

Yeah, it's not a bid deal.  The cygwin port will theoretically be the same
as the linux port, as they both use basically the same libraries.  GL might
be an issue, but that's about it.  the MSVC++ port will require different
code, as that compiler is so screwed up it isn't funny.  ALthough I haven't
tried vc++7 yet, vc++6 had so many ansi incompatibilities, I just gave up
on it.

Other stuff: the source would seem to require smpeg.  I downloaded the
windows library and dev stuff, and that was no problem.

WHat's going on with all the stuff in libs? is that the main stuff we have
to replace? it's so full of macros, I can't even tell what the heck its
trying to do.  I commented out a bunch of it to get SDL_wrapper to compile,
things are almost compiling now.  libs seems rather heavily 3d0 dependent.

Re: [sc2-devel] windows compilation

[Mudrony <mu...@in...>]

2002-08-17, szo keltez=E9ssel Alon Tirosh ezt =EDrta:
> ok. we need to figure something out. Some of the people dev'ing for windo=
ws will be doing it in VS, and some people want to use ming. this can cause=
 problems. personally i like to use VS because it gives me a better Debugge=
r and i can look at the asm and tune the code better. this is just me. howe=
ver, if we dev under two diff compilers, while both final products will wor=
k, we can have cross development issues. so. what to do?

I think it will be fine until we do not try to link code from different
compiler together! The data should work fine with both, and the souce
must go with both..

[Sc2-devel] desgn and cvs

[Mudrony <mu...@in...>]

2002-08-17, szo keltez=E9ssel ze...@rp... ezt =EDrta:
> I just tried out Karl's configure file in cygwin and it creates the
> makefile fine.	(I had to install the SDL_mixer and image libraries I
> downloaded off the sdl site by hand, though).  Now to work on getting
> everything to compile with mingw.  I know vc++ is an option, but I think =
it
> better that it also works on the free alternative.  It's not that hard to
> get mingw working with SDL and OGL, either, I have successfully compiled
> the SDL/OGL demo.  NOw to try to get it to compile.

I'm using Cygwin/mingw for my clone (fscp) for SDL and OpenGL, and it
works perfect.. (well the cygwin gl.h is only 1.1 by default, wich lacks
some essential multitexture stuff.., but semms it can be made 1.2
compilant with a define)

I will work on the linux port (dling the src, and Karl's stuff right
now). I will do some autoconf/automake stuff and suggest using freetype,
SDL-SGE, and similar stuff. I might even try making some design
suggestions, and even migrating some of my code in, if people see it
fit.=20

At the beginning of FSCP SDL was weak and GGI looked much better (it was
long time ago), however we didnt wanted to commit ourselves to just one
backed, and decided to do the modular thing, wich I suggest to de here
as well. Define a consistent api and hide all gfx baxked specific stuff
(like SDL) behind it, so your higher level stuff gets cleaned and
porting will be less pain. My gfx engine evolved to a level where it
does advanced OpenGL stuff and even hides differences in 2d/3d...
(http://fscp.sf.net/screenshots/)

Well fisrt lets make SC2 code to compile under linux..

One more thing: CVS checkouts will complain that files in the way if i
download the sources myself, and will want to redownload then itself.=20
So please make the CVS subdirs available as a separate download, or make
CVS complete soon..

>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> Sc2-devel mailing list
> Sc2...@li...
> https://lists.sourceforge.net/lists/listinfo/sc2-devel

[sc2-devel] windows compilation

[Alon T. <al...@ay...>]

ok. we need to figure something out. Some of the people dev'ing for =
windows will be doing it in VS, and some people want to use ming. this =
can cause problems. personally i like to use VS because it gives me a =
better Debugger and i can look at the asm and tune the code better. this =
is just me. however, if we dev under two diff compilers, while both =
final products will work, we can have cross development issues. so. what =
to do?

Re: [Sc2-devel] Compiling under linux

[<ze...@rp...>]

I just tried out Karl's configure file in cygwin and it creates the
makefile fine.	(I had to install the SDL_mixer and image libraries I
downloaded off the sdl site by hand, though).  Now to work on getting
everything to compile with mingw.  I know vc++ is an option, but I think it
better that it also works on the free alternative.  It's not that hard to
get mingw working with SDL and OGL, either, I have successfully compiled
the SDL/OGL demo.  NOw to try to get it to compile.

[Sc2-devel] Compiling under linux

[Karl B. <ka...@gm...>]

Hi all!

I've put together a simple configure/Makefile for sc2. It can be found at:

http://www.linux-games.com/make.tar.gz

Extract the tar into the src directory, than go into the configure dir
and call ./configure . Then you should have a usable Makefile.

Problems (can all be fix easily) :

- SDL_wrapper.h:41: gl/glut.h should be GL/glut.h
- IKEY_CON.H should be lowercase
- IFONTRES.H should be lowercase
- ISNDRES.H should be lowercase
- sc2code/libs/math/random.c: random is defined here, but it's
     also defined in /usr/include/stdlib.h. It looks like we don't
     need the one in sc2code/libs/math/ IMHO.

Notes:

- I added the following defines, since they are needed (I used
     the values from Starcon2.dsp):
       SAFE_X=0
       SAFE_Y=0


It doesn't compile successfully, yet, but I think it's a good starting
point. I'll probably post an updated version tomorrow.

I hope this helps,

-- linux-Gg

[Sc2-devel] Compiling under linux

[Karl B. <ka...@gm...>]

Hi all!

I've put together a simple configure/Makefile for sc2. It's attached. 
Extract the tar into the src directory, than go into the configure dir 
and call ./configure . Then you should have a usable Makefile.

Problems (can all be fix easily) :

- SDL_wrapper.h:41: gl/glut.h should be GL/glut.h
- IKEY_CON.H should be lowercase
- IFONTRES.H should be lowercase
- ISNDRES.H should be lowercase
- sc2code/libs/math/random.c: random is defined here, but it's
   also defined in /usr/include/stdlib.h. It looks like we don't
   need the one in sc2code/libs/math/ IMHO.

Notes:

- I added the following defines, since they are needed (I used
   the values from Starcon2.dsp):
     SAFE_X=0
     SAFE_Y=0


It doesn't compile successfully, yet, but I think it's a good starting 
point. I'll probably post an updated version tomorrow.

I hope this helps,

-- linux-Gg

[Sc2-devel] sc2 in mag

[Nick B. <nic...@ma...>]

Oh, btw, there was mention of the new SC2 project in a computer
gameing magazine. I scanned it and sent it off to the news section at
PONAF.
_______________________________________________________________
 http://www.webmail.co.za the South-African free email service

[Sc2-devel] re: webpage

[Nick B. <nic...@ma...>]

aargh, this is in digest mode, got to turn off...

Anyways, I would love to help with the webpage:

-Nick
_______________________________________________________________
 http://www.webmail.co.za the South-African free email service

[Sc2-devel] sample aif->wav

[P S. <pjs...@un...>]

for those who can't compile the little program,

http://www4.ncsu.edu/~pjspycha/files/SHIPYARD.WAV
thanks to Meep-Eep (Serge van den Boom)

[Sc2-devel] The process begins

[Chris N. <ch...@to...>]

Hello, everyone. 

Today, the source code have been posted to cvs.sc2.sourceforge.net, the
media is currently being uploaded (we'll see whether sourceforge gives
us the ~500 megs of storage space we need), and the open development
phase of the re-release of The Ur-Quan Masters begins. 

There are many development models we could use. To date, I've been the
only one making changes to the code itself (along with Fred), and have
been utilizing your abilities by giving detailed coding assignments.
These assignments allow me to offload problems that are more generally
solvable, so I can work on the problems that require a better
understanding of the sc2 sourcecode itself. Thus, everyone works on the
tasks that they are best suited for. This has worked very well, and I
think it's a pretty efficient way to get things done. 

There are other models. I could, for example, open up the CVS
repository, and allow anybody to directly make changes to code and
media. Although this allows for a faster theoretical maximum development
speed, it also introduces the possibility of more bugs, and a somewhat
more chaotic atmosphere. This might be better suited for other projects
that would like to branch off, after we hit v1.0... 

If anyone disagrees, or wants to offer a different model, please post to
the list. 

Also, we have 32(!) people as far, on this list. To ensure that this
list doesn't generate too much traffic, I would encourage people to
limit their posts to the primary topic: development. We also have a
channel on irc.openprojects.net: #sc2. If you're working on an
assignment, having a presence in this channel would be a good idea, so
you can collaborate with other people who might be working on the same
thing. The channel also is a better place to just chat about the
project, in general, without flooding peoples inboxen. 

The first assignment is for everyone to download the project (all 500
megs), and verify that it compiles + runs, if you're running some flavor
of windows. You'll need some libraries, specifically SDL, SDL_image, and
SDL_mixer. These can be obtained at libsdl.org... 

For those of us who'd rather work in Linux, our first job is to get the
code to compile there. This is probably one of the next things I'll be
working on.

So over the weekend, feel free to examine the code, or try to make it
work under Linux (document your changes!). I'll be unavailable this
weekend, and will start giving assignments sometime next week.

Enjoy!

-Chris

[Sc2-devel] aif to wav convertor

[Serge v. d. B. <sv...@st...>]

Hi,

I've made a convertor for the .aif files. Parker found a file which
converted uncoded files to SBX2 coded files, which provided all
the info still needed.
Note that the .aif files are long, and the converter isn't optimised,
so you may have to be a little patient.

Greetings,

Serge


P.S.  A lot of us are on irc on irc.openprojects.net, channel #sc2. Feel
      free to join us if you're not already there.

RE: [Sc2-devel] sc2.sourceforge.net

[Scott I. <xr...@cl...>]

Well I've been in contact with Chris and haven't heard from
EvilSpaceL0ord, and so Ive taken a start to creating a layout for this
site.
Ill have something to view fairly soon.
 
   Scott,

-----Original Message-----
From: sc2...@li...
[mailto:sc2...@li...] On Behalf Of P Spychala
Sent: August 15, 2002 1:37 PM
To: sc2...@li...
Subject: [Sc2-devel] sc2.sourceforge.net


Who is interested in doing the sourceforge webpage for us? Chris told me
that Scott and EvilSpaceLord were interested, anyone else?

[Sc2-devel] Hi All (sorry if this is not the done thing)

[Nick B. <nic...@ma...>]

I am not sure I can help much I just dont have the time, but maybe I
can offer help if its asked for ;)

_______________________________________________________________
 http://www.webmail.co.za the South-African free email service