[##UnknownPlayer##]

MSVC++ workspace and project files have been uploaded to the CVS. They compile properly into a playable exe.
Look over the custom build steps before use since I was messing around with them just before I uploaded.

Let the coding begin!

[EDIT] By workspace and project files I mean 'real' workspace and project files for MSVC [/EDIT]

[DTP]

bawhahaha, just made them real too. LOL
so i guees,i dont need to commit.

just to checkout again.
--------

edit: before you start altering your options in msDEV, you may want to remove the Write protection.

altered a bit, and then, write protection.

----------
somehow all the files are write protected cpp, .h .rc.

uhmm.

wonder if it is just my system
-----------------

[penguin]

Originally posted by DTP
somehow all the files are write protected cpp, .h .rc.

Are you using WinCVS?  The default options are a little screwy... when you checkout or update, see if there's a checkbox for "read-only files" or similar.

[DTP]

thx, yeah, there where not immediate apperant option to not write protect things.

[DTP]

Originally posted by ##UnknownPlayer##
MSVC++ workspace and project files have been uploaded to the CVS. They compile properly into a playable exe.
Look over the custom build steps before use since I was messing around with them just before I uploaded.

Let the coding begin!

[EDIT] By workspace and project files I mean 'real' workspace and project files for MSVC [/EDIT]

ahm, I think you broke something

This will not compile with MS VISUAL STUDIO c++ 6.0 Enterprise edition.

i am getting 2 errors regarding #include "config.h". a file not included in the project.

The errors are that it cannot open the file "config.h".

If i add it to the project, im getting a similar error

cannot open

That file i do not have as default in my include directories.

leaving out the #include "config.h" will not solve, as i then i get some other 4 errors.

What MS Compiler are you using?? full name please.
have you added some files to the include list?.

im using MS VISUAL C++ 6.0 from the enterprise edition.

maybe your include directories differs from mine, and if so, many other peoples, since i use the defaults.

I opened the freespace2.dsw file and not the fs2_open.dsw

that may be my error, but the fs2_open.dsw seemed to be the old fs2_open.dsw.

and this will hopefully run fine, once i get all this downloaded again.

I deleted it, because i began getting a bunch of errors, that should not be there.

[Inquisitor]

Erf, the one I put up and penguin edited worked in enterprise

UP, maybe it's time for a rollback

Grab me on IRC, maybe we can muddle thru this before end of day

[##UnknownPlayer##]

Ok - I was out for the day today so I only just saw all this then.

The files I uploaded are access from the freespace2.dsw - the original fs2_open ones are left as they were. I did all my work in MSVC++ 6.0 Standard so there should be no compatability problems.

Make sure you're using freespace2.dsw and NOT fs2_open.dsw

[Inquisitor]

My bad.

I thought you just updated the one me and penguin worked on.

I'll mark the right one, sorry about the confusion folks.

[WMCoolmon]

I am also getting the unistd.h error
EDIT: Is stubs.cpp really needed? It looks like I can compile fine without it.

[penguin]

Originally posted by WMCoolmon
I am also getting the unistd.h error
EDIT: Is stubs.cpp really needed? It looks like I can compile fine without it.

stubs.cpp should not be included unless you are doing a Unix build.  Not sure how that snuck in... it wasn't in the fs2_open.w32.mak makefile...

I have heard other reports of the "unistd.h" include file, and I'm not sure why that's happening... is should be protected inside the

Code: [Select]


#if defined _WIN32
    // windows stuff
#else
    #include
    // other unix stuff
#endif

If _WIN32 is not being defined, many, many things will break...   _WIN32 is supposed to be defined always, according to MSDN; with my setup it does seem to work, so I'm curious about what's different.

As a quick fix, try adding "/D _WIN32" to the compile command line for all the .cpp files and see if it changes anything.

[Inquisitor]

Quick fix, open a new VS project file, select "import makefile" and import the fs2 makefile.

I KNOW that compiles, that's what I used to do the initial project file.

[WMCoolmon]

penguin: Here's the problem, I was compiling stubs.cpp-I recompiled without it and it finished. So, all that needs to be done is to add "config.h" to the project and in pstypes.h set it to be "../windows_stub/config.h". At least, that worked for me

[##UnknownPlayer##]

This is really curious, since I downloaded a fresh copy from the CVS and using my workspace as stored on the CVS it works fine.

stubs.cpp I left in, I added additional protection in the OpenGL code with a WIN32 inclusion guard (which I put as defined in the project files). All in all, it should compile 'as is' when you download it.

[DTP]

oright, trying to compile again. will report backon progress

[DTP]

hmmm, for some reason, those external dependacies where not updated until i rolled out the file list, so that initial error. could not find "config.h" where eliminated.

maybe worth noting in the readme.

but when they where, i could compile fine.

I am the only one that is getting that winsock related macro redefinition warning like 6 times

warning;

C:\Programmer\Microsoft Visual Studio\VC98\INCLUDE\winsock.h(366) : warning C4005: 'INVALID_SOCKET' : macro redefinition
        E:\NEW_DIR\fs2_open\code\Network\psnet2.h(93) : see previous definition of 'INVALID_SOCKET'

---------------------
winsock.h line 366

#define INVALID_SOCKET  (SOCKET)(~0)
-----------------
redefined here
-----------------
psnet2.h near line 93;

#undef INVALID_SOCKET
#define INVALID_SOCKET (PSNET_SOCKET)(~0)
------------------

seems that #undef is uneffective.

And i am getting 1 other warning of a possible usage of a local variable not initialized

warning;

E:\NEW_DIR\fs2_open\code\Hud\HUDconfig.cpp(1088) : warning C4701: local variable 'use_color' may be used without having been initialized

just curios. i know warnings can sometimes be taken lightly, but a possible usage of local variable not initialmized is a possible crash point to me.

[penguin]

The INVALID_SOCKET warning is just an annoyance -- it can safely be ignored, we'll squelch it one of these days...

The use_color warning in hud_config_render_gauges() is far more pernicious; I am assuming that block of code (the else clause) is never executed; as you point out, this is a segfault waiting to happen, especially since use_color is a pointer...

All of the alphacolor code caused me much grief when I was working on the Linux port... there is a lot of strangeness going on in that code.

Edit:
Ack!  This is a bug I introduced in an attempt to fix something else ... I see what's going on and will fix it RSN

[DTP]

ok thx for response.
EDIT.
bug, ack. good you caught it.

[penguin]

fixed, I think... stupid alphacolors.

It's committed to CVS, file revision 2.1; the patch is below FYI:

Code: [Select]


@@ -1058,10 +1061,10 @@
 void hud_config_render_gauges()
 {
  int i;
- color *use_color;
- int alpha;
 
  for ( i=0; i+ color *use_color;
+ int alpha;
  if ( (hud_config_show_flag_is_set(i)) ) {
  // set the correct color
  if(!HC_gauge_regions[gr_screen.res][i].use_iff){
@@ -1085,8 +1088,9 @@
  gr_set_color_fast(use_color);
  } else {
  // if its off, make it dark gray
- gr_init_alphacolor(use_color, 127, 127, 127, 64);
- gr_set_color_fast(use_color);
+ static color use_color;
+ gr_init_alphacolor(&use_color, 127, 127, 127, 64);
+ gr_set_color_fast(&use_color);
  }
 
  // draw


[DTP]

Yeah, now its all fine, except for them macro redef.

But it works here as well.