[Mysterial]

I would suggest NOT using gcc 3. I've heard nothing but complaints of bugs with regard to it.

SDL's performance has always been excellent for me, no matter if the graphics are 3D or 2D. I wouldn't know about OpenGL.

OpenAL is a good choice for sound. SDL's sound routines aren't all that great. They're not bad, but when you have good alternatives, why not use them? Most people who do use SDL sound also use the sdl_mixer addon library for it, which seems to need a different patch for every game that people want to write with it. Plus on my system it lags a bit, although that might just be my computer not liking it for some reason.

BTW vrodic, nice work on the assembler conversions. That was the sticky point for me. I hate assembly.

[EvilTypeGuy]

Originally posted by vrodic

I'm supporting the candidature of Mike Harris (penguin) for this role. I also support  Inquisitor. I would just like to get off this forum and start doing some group programming ASAP Warpcore CVS seems to be the ideal place for the code, and warpcore mailing list at  http://www.descent-freespace.com/lists/fdl/ seems to be the ideal place for discussion.
 

As I told inquisitor, when someone's decided on who wants to be the Project Lead, i'll need the following information:

1) Project Name / Affiliation
2) Project Leader's Real Name / email address
3) Project Goals (i.e. do you plan on making a port to Linux at some point, or
                  you are at least open to it, and willing to use SDL/OpenGL)
4) Desired warpcore.org domain, example: projectname.warpcore.org
5) Is a mailling-list desired/wanted?
6) Is bugzilla desired/wanted?
7) Any extra comments, etc.

Again, this is an open offer, I'm glad to see someone with the knowledge take up the torch and begin this process. Just contact me at the address below when ready.

Great progress in a short amount of time Vrodic, very commendable.

DrEvil
[email protected]

[EdrickV]

Aside from MingW, how would I get the other files needed to compile this version? Do I have to download the entire DX7 SDK & the Platform SDK in order to get a few header files? And how exactly do you build it? Do you use ./Build.sh? (And do I have to have Dev-C++ or something? I have Cygwin with GCC 2.95.3-5 and installed the MingW files over the ones that were already there.) I'm used to ./configure; make; make install for installing programs, or rather seeing what programs won't install on Cygwin.

[_argv[-1]]

Originally posted by Mysterial
I would suggest NOT using gcc 3. I've heard nothing but complaints of bugs with regard to it.

I would suggest trying it before making a cursory dismissal. It might actually work...

SDL's performance has always been excellent for me, no matter if the graphics are 3D or 2D. I wouldn't know about OpenGL.

I've only seen OpenGL 2D being drawn as textured 3D polys. That doesn't mean it's the only way, of course. In any event, 2D performance probably won't matter enough to warrant the trouble of using anything else. If it does, then SDL provides 2D drawing routines of its own for you to draw with.

OpenAL is a good choice for sound. SDL's sound routines aren't all that great. They're not bad, but when you have good alternatives, why not use them? Most people who do use SDL sound also use the sdl_mixer addon library for it, which seems to need a different patch for every game that people want to write with it. Plus on my system it lags a bit, although that might just be my computer not liking it for some reason.

I agree. From what I'm able to tell, OpenAL makes 3D audio support a piece of cake, whether you have 3D audio hardware or not. It also has extensions (a la OpenGL extensions) for loading Ogg Vorbis audio, so using that for audio/music would also be a piece of cake.

With regards to it lagging on your system, would you happen to be running it through esd by any chance? Esd lags a lot. I understand OpenAL is somewhat incomplete on Windows, but that's probably improved since I heard about that. Anyway, it doesn't have to work perfectly -- you still get a big payoff later, since you get great 3D audio with a minimum amount of effort.

[Sandwich]

Geez - I'm glad I didn't apply for managing the source code project - I don't understand half the stuff here!

You guys rock.

[vrodic]

Originally posted by EdrickV
Aside from MingW, how would I get the other files needed to compile this version? Do I have to download the entire DX7 SDK & the Platform SDK in order to get a few header files? And how exactly do you build it? Do you use ./Build.sh? (And do I have to have Dev-C++ or something? I have Cygwin with GCC 2.95.3-5 and installed the MingW files over the ones that were already there.) I'm used to ./configure; make; make install for installing programs, or rather seeing what programs won't install on Cygwin.

Yeah, use ./build.sh.

I mentioned dx7 headers in README.win32 because thats what I use. But dx5 or dx8 should do too.

Go grab the headers at http://quark.fsb.hr/vedran/myfs2/headers.zip

[EdrickV]

Those headers did the trick! Once I put them in the right spot. (I dropped them into the DirectX folder which was empty.) I can see why they didn't like to do Glide debugging on one system though. Tried bringing up my Stinger model in the tech room (the bad one) and expected it to crash. Didn't expect it to popup an error message where I couldn't see it and not let me get to it. Oh well. Couldn't see whatever error messages it was giving. The windowed mode doesn't seem to work on my computer, anyone else tried GGC-FS2 in D3D mode with the -window command line argument? (We'll have to make some sort of config program to change the settings you'd set in the launcher.) Now I'll have to get that dsp->make file conversion script and see if I can get any of the other programs working. Like the POFView I've been so curious about. And then I'll see what I can do with the source.
:devilidea

[Mysterial]

Originally posted by _argv[-1]


I would suggest trying it before making a cursory dismissal. It might actually work...

I'm not going to try something that has filled up the mailing lists of every library I use with messages that it doesn't work. Of course it might, but unless there's some feature or bugfix we just must have, I think we shouldn't use it. Of course that's just my opinion.

With regards to it lagging on your system, would you happen to be running it through esd by any chance? Esd lags a lot. I understand OpenAL is somewhat incomplete on Windows, but that's probably improved since I heard about that. Anyway, it doesn't have to work perfectly -- you still get a big payoff later, since you get great 3D audio with a minimum amount of effort.

I don't know what intermediates the library is using on my system (it's Linux that it lags on) but you're probably correct. Thanks for the info, maybe there's something I can do about it.

I don't know about OpenAL's implementation on Windows - I've heard it wasn't that bad, but I haven't actually used it myself except on Linux. In a worst case scenario though, we could always leave in the DirectSound code in a seperate source file for Windows and use #defines.

[vrodic]

Originally posted by EdrickV


Those headers did the trick! Once I put them in the right spot. (I dropped them into the DirectX folder which was empty.) I can see why they didn't like to do Glide debugging on one system though. Tried bringing up my Stinger model in the tech room (the bad one) and expected it to crash. Didn't expect it to popup an error message where I couldn't see it and not let me get to it. Oh well. Couldn't see whatever error messages it was giving. The windowed mode doesn't seem to work on my computer, anyone else tried GGC-FS2 in D3D mode with the -window command line argument? (We'll have to make some sort of config program to change the settings you'd set in the launcher.) Now I'll have to get that dsp->make file conversion script and see if I can get any of the other programs working. Like the POFView I've been so curious about. And then I'll see what I can do with the source.
:devilidea

-window works on my Radeon on WinXP Home just fine.

I've put dsp2mak.awk in tools directory of the source tree.

[EdrickV]

Originally posted by vrodic

-window works on my Radeon on WinXP Home just fine.

I've put dsp2mak.awk in tools directory of the source tree.

-window probably doesn't like my video card. Will see what I can figure out about that. As far as dsp2mak.awk, I couldn't find that (though I found the source code for an exe of the same name) but I did find a dsw2mak.awk file here:
http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/software/msds/index.html
I think the dsw one may be newer then the dsp one, and it looks like it went and made mak files for all the dsp files.
Did you have any trouble with the program wanting afxwin.h? Haven't been able to get POFView to compile yet because it wants that and other MFC headers and I get errors when trying to use the ones I have.

[vrodic]

Originally posted by EdrickV

-window probably doesn't like my video card. Will see what I can figure out about that. As far as dsp2mak.awk, I couldn't find that (though I found the source code for an exe of the same name) but I did find a dsw2mak.awk file here:
http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/software/msds/index.html
I think the dsw one may be newer then the dsp one, and it looks like it went and made mak files for all the dsp files.
Did you have any trouble with the program wanting afxwin.h? Haven't been able to get POFView to compile yet because it wants that and other MFC headers and I get errors when trying to use the ones I have.

It's the same script.

It's in the current cvs, remember to update here and then

Keep in mind that I had to modify the resulting makefiles for things to work.
You should get it working with -window somehow. It will be hard to debug anything without that. Of course, real men don't use debuggers But I cheated. I debugged some functions with latest cygwin gdb.exe (nice win32 app), and I tried looking at some string variable values but  all I could see is junk. I'm not sure if it's a gdb bug, or maybe the fact I'm using -mno-cygwin...  It's still useful for tracking code paths, but so is grep. So I guess I'll dump gdb soon.

Right now I'm removing Microsoft specific cruft. (don't worry, it still works under Windows).

I'll probably be developing under windows (yuck!) until the point I've ported things to OpenGL, OpenAL (or whatever) and SDL for input. I just downloaded bloodshed dev-c++. I hope it's nice.

About MFC, I'm afraid I'll go blind if I see MFC code again

[_argv[-1]]

Originally posted by Mysterial
I'm not going to try something that has filled up the mailing lists of every library I use with messages that it doesn't work. Of course it might, but unless there's some feature or bugfix we just must have, I think we shouldn't use it. Of course that's just my opinion.

I said that because whatever bugs there were may have been fixed by now.

I don't know what intermediates the library is using on my system (it's Linux that it lags on) but you're probably correct. Thanks for the info, maybe there's something I can do about it.

esdctl off

...will let OpenAL use your audio device directly. To reverse this,

esdctl on

If you get no sound after doing 'esdctl off', OpenAL must be somehow configured to always use esd, rather than trying the audio device directly first. That configuration will need to be changed.

I don't know about OpenAL's implementation on Windows - I've heard it wasn't that bad, but I haven't actually used it myself except on Linux. In a worst case scenario though, we could always leave in the DirectSound code in a seperate source file for Windows and use #defines.

I'm glad you consider that a worst-case scenario, because that would get pretty damn ugly.

[EdrickV]

Just did a CVS update. Didn't get a tools folder or that dsp2mak script. I don't think it's the same as the dsw2mak script, unless you have dsp files and a makefile file you didn't publish in the CVS tree. (They were likely made by the same person though and the dsw probably has the dsp->mak code in it plus the dsw->makefile conversion code.)

[vrodic]

Originally posted by EdrickV
Just did a CVS update. Didn't get a tools folder or that dsp2mak script. I don't think it's the same as the dsw2mak script, unless you have dsp files and a makefile file you didn't publish in the CVS tree. (They were likely made by the same person though and the dsw probably has the dsp->mak code in it plus the dsw->makefile conversion code.)

cvs update -Pd please I had to modify the Makefiles to make things work. I also removed some redundant stuff.

It's the same thing, different filename. I checked. I wouldn't say so if I didn't

[el84]

I installed Cygwin, downloaded mingw-runtime-2.0-20020430.tar.gz and put the files in the correct directories, and grabbed the cvs tree this afternoon. But Gcc complains that it can’t find declarations/definitions for a few functions (“implicit declaration of function … “):

os_message
os_launch
os_error_message
os_copy_file
.. and a few others

And gcc squeaks each time a vector or matrix is initialized. For instance:
“Freespace.cpp:3218: warning : aggregate has a partly bracketed initializer”

I’m not too worried about the warning. Don’t think it would prevent successful build. Gcc is just *****ing that a flat initializer was used. Shouldn’t be too difficult to quash those warnings (the answer is somewhere in TCPL, just have to find it).

But without the os_* functions, I am dead in the water. I must be missing some library, but which one?

[EdrickV]

Originally posted by el84

os_message
os_launch
os_error_message
os_copy_file
But without the os_* functions, I am dead in the water. I must be missing some library, but which one?

Think you may have gotten the function names wrong, since I can't find anything like that in the source or the cygwin GCC includes. Did you get the Direct X headers and put them into the Direct X folder? And how exactly did you try to build it? (And get used to warnings, there are lots of them when compiling the source and in particular the code.lib file, which can take quite a while the first time.)

Edit: By the way, you can get rid of a couple warnings by putting:
-include "/PsTypes.h" before the -I lines in the makefiles.
VC++ used a /FI"PsTypes.h" (force include) to include the file before any other includes, but the awk script didn't recognize that command line option as the same thing as GCC's -include.

[vrodic]

Originally posted by el84
I installed Cygwin, downloaded mingw-runtime-2.0-20020430.tar.gz and put the files in the correct directories, and grabbed the cvs tree this afternoon. But Gcc complains that it can’t find declarations/definitions for a few functions (“implicit declaration of function … “):

os_message
os_launch
os_error_message
os_copy_file
.. and a few others

And gcc squeaks each time a vector or matrix is initialized. For instance:
“Freespace.cpp:3218: warning : aggregate has a partly bracketed initializer”

I’m not too worried about the warning. Don’t think it would prevent successful build. Gcc is just *****ing that a flat initializer was used. Shouldn’t be too difficult to quash those warnings (the answer is somewhere in TCPL, just have to find it).

But without the os_* functions, I am dead in the water. I must be missing some library, but which one?

Try cleaning up the tree cd code;make -f code.mak clean; cd .. ;make -f Freespace2.mak clean

This is because dependancy system doesn't work yet with the makefiles.
I've added these platform abstaction functions in OsApi.cpp that are used across several files now.

[EdrickV]

Ok, it seems what I thought was wrong wasn't. The current CVS revision (1.3) is broken 'cause he replaced the win api function calls with those calls but did not actually make the functions. You need to get rid of that copy, get the 1.1.1.1 copy (add a -r 1.1.1.1 after the co) then you'll need to update to 1.2. cvs update -Pd -r 1.2 should work. I think. I'm new to CVS. Wish he'd not posted the code like that when it's unusable. (If anyone here knows how to "roll back" a current version with locally modified files to an earlier version your input would be useful.)

[EdrickV]

As of right now, there is still at least one function missing: os_error_message() And yes I did make cleans. There also seems to be no limits.h file.

[vrodic]

Originally posted by EdrickV
As of right now, there is still at least one function missing: os_error_message() And yes I did make cleans. There also seems to be no limits.h file.

Sorry. Should be fixed now. Code was there, but wasn't checked in.

But you should have limits.h with your mingw distribution.

Regarding retrieving older versions, I tagged the "stable" release. Update or check out the tree with -r really-before-mayhem

That said, I try to keep HEAD version compilable and tested.

And dependancy system should really be made work. It should work, since the Makefiles CAN generate .dep files with
make -f ... depends, but it doesn't please feel free to fix it...

Another thing, I made the CVS viewable with http://quark.fsb.hr/cgi-bin/viewcvs.cgi

You can browse changes, look at the differences between files etc there. Check it out.