how i compiled bzflag-2.0.10 source winxp msvc++8 express

Questions or HOWTOs about the above? Post 'em here...
Post Reply
SkindupTruk
Private First Class
Private First Class
Posts: 19
Joined: Fri Apr 11, 2008 10:17 pm

how i compiled bzflag-2.0.10 source winxp msvc++8 express

Post by SkindupTruk »

i recently took the plunge to compile bz-2.0.10 on winxp sp2.

i worked closely off the readme file in the win32 dir of the bz source.

i'll try to remember the steps based on what i have on my hdd now:

1. msvc++ 8 express
2. winxp sdk
3. directx sdk
4. libcurl-7.18.0-win32-msvc.zip
5. ncurses-5.6.tar.gz
6. load the .sln file (bz solution file)
7. point the IDE to all the lib and include dirs
8. hit the magic "compile solution"

from here i kept an eye on the compiler warnings and errors. warnings are ok to ignore, you'll get around 100 in total. any single error though is a killer. each error is unique so get this far and post your errors!

i remember a few i resolved by copying in some win32 binary install game dll's into the build dir... it was on these forums somewhere. looking at the hdd again, seems they were:

msvcr71.dll
libcurl.dll

finally i got no errors, everything built! i tried out my new bzfs, then connected to it with my new bzflag, it worked great. now here's the interesting part.

i then got an old patch for a new type of flag i wanted to try out. it required both server and client changes. i didn't want to bother with SVN because i don't know how to use it and patch in winxp. so i hand patched a few parts of the new code, and it recompiled ok.

i took in my two new .exe's into the office for our daily lunch hour bz bash, and got this :(

http://typethinker.blogspot.com/2007/12 ... ation.html - i got a laugh from the "rant" part because it's so true!

it then took me just as long to fix this up as it took me to do all of the above! i don't have the details of the solution here, but here were the steps to make it run on a new pc without all of the dev stuff above. the variable names are guides, don't take them literally:

1. goto control panel, computer management, and get to event log. look for errors to do with SxS (side by side). mine was to do with MSVC.debugCRT, which is the C runtime library.
2. i researched the error, and found you don't just put dll's in the same dir anymore. you need a new dir named just right, containing not just the dll's but a .manifest file in xml with extra info.
3. on the new pc, i put bzfs.exe and bzflag.exe in a new dir
4. next to them, i made a new subdir i magically called MSVC.debugCRT
5. inside that subdir, i put a MSVC.debugCRT.manifest file found thru google, containing lots of magical numbers and values in xml
6. the manifest named a few dll's, so thru random dll sites, i put them in the subdir.
7. i ran bzfs again, and it went past the old error. but now it wanted more dll's!
8. kept adding dll's one at a time as above. remember to enter a new line in the manifest for each one. one time i recompiled with a slightly changed if statement, and it wanted a whole new dll! beyond me.
9. eventually the .exe runs, and we're back online with new flags :)
10. i plan on making more new flags that simply combine existing flags powers as practice. then try making totally new weapons like a mortar or the good old C&C Ion Cannon!

i liked this solution because unlike other scary stuff i saw while researching, it didn't require me to build new libraries, or require hard to find options in the express version of the IDE to "static link" libraries, or even to "install" anything. it ended up being a copy and paste job.

anyway, like i said, every journey is different so just jump in and have a go. i spent longer thinking about getting into it than it took to install, compile, troubleshoot, migrate, troubleshoot again, and finally play!
Last edited by SkindupTruk on Fri Jun 06, 2008 5:14 pm, edited 1 time in total.
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

You don't want to build debug if you are going to share the version, build release. That will get you around most of the dll problems.

if you are going to modify gameplay, please change your protocol version number so that your clients are incompatible with the release version and can not be used as cheats.

It really is best to learn how to program first before you hack on bzflag.
ImageJeffM
User avatar
blast
General
General
Posts: 4933
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Post by blast »

You can't share the version anyway, since you are building with Visual C++ 2005 Express Edition, which prohibits sharing any binaries you build. If you want to allow other people to run it, you will have to have the full version of Visual C++ or Visual Studio and build it with that.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image
SkindupTruk
Private First Class
Private First Class
Posts: 19
Joined: Fri Apr 11, 2008 10:17 pm

Post by SkindupTruk »

JeffM wrote:You don't want to build debug if you are going to share the version, build release. That will get you around most of the dll problems.

if you are going to modify gameplay, please change your protocol version number so that your clients are incompatible with the release version and can not be used as cheats.

It really is best to learn how to program first before you hack on bzflag.
well, that was a terse response.

interesting point about the debug vs release, i'll try that to see what happens.

any pointers about changing the proto #?

i'm afraid i find your last comment a little offensive, especially since my first post here was an attempt to be instructional. not a good example to set for others who are tentative i think.

you are half right in that i am not a programmer by trade. clearly i have breached some sort of protocols and conventions. but to publicly label some creative tinkering with an open source project, especially coming from the #1 poster on the forums, as a "hack on bzflag" is a bit OTT isn't it mate?! :?
Last edited by SkindupTruk on Fri Jun 06, 2008 5:12 pm, edited 1 time in total.
SkindupTruk
Private First Class
Private First Class
Posts: 19
Joined: Fri Apr 11, 2008 10:17 pm

Post by SkindupTruk »

blast wrote:You can't share the version anyway, since you are building with Visual C++ 2005 Express Edition, which prohibits sharing any binaries you build. If you want to allow other people to run it, you will have to have the full version of Visual C++ or Visual Studio and build it with that.
please define share. i believe i can run these binaries on any winxp sp2 box with the .manifest sxs workaround. by believe i mean i've run it on a few, so i can't be sure if its some sort of luck. they don't have any devel stuff on them, they're pretty plain installs of winxp sp2.
User avatar
blast
General
General
Posts: 4933
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Post by blast »

You aren't allowed to distribute it. It's part of the license you would have agreed to when you installed the software. The fact that you have to use a workaround is a sign they don't want you doing that.

As for changing the protocol, search for 0026 in the code. It'll be in the date project. You could change that to something like 9826. That way you can still use the list server and it's services, but only people with that modified client could play together.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

SkindupTruk
"hack on" is slang for "putter around with the code" in the OSS communities.

to change the protocol version simply open

src/date/buildDate.cxx and change this line

# define BZ_PROTO_VERSION "0026"

change the "0026" to something else like "9999" then all will be good.

and yes blast is correct, the express edition is only licensed for personal development not distribution. This is doubly true of the debug builds in any version of VC++, MS does not allow redistribution of the debug runtime DLLs, that is why they are not installed with the runtime kit. It is a legal/licensing issue, not a technical one (tho that is one reason you had to hack it out, because they try to prevent it )

my comment on learning to program is simply advice. It's good to want to learn how to do code, but bzflag is not the best tool in the world for learning, and in my opinion it's a lot better for you if you learn a little bit more about programing and your development environment before you get too deep into bzflag. It will help you a lot in the long run, no offense was meant.
ImageJeffM
Reven
Private
Private
Posts: 2
Joined: Mon Jun 23, 2008 3:18 am

Post by Reven »

blast wrote:You can't share the version anyway, since you are building with Visual C++ 2005 Express Edition, which prohibits sharing any binaries you build. If you want to allow other people to run it, you will have to have the full version of Visual C++ or Visual Studio and build it with that.
Can you quote a reference on that? Microsoft seems to think differently. From the Microsoft Visual Studio Express FAQ:
Microsoft wrote: 4. Can I use Express Editions for commercial use?

Yes, there are no licensing restrictions for applications built using the Express Editions.
This is, of course, the FAQ for the newer VS 2008. However, even if this were different for the 2005 version, I highly doubt they would make 2008 more liberal and then make trouble over distributing executables made with 2005.
Reven
Private
Private
Posts: 2
Joined: Mon Jun 23, 2008 3:18 am

Post by Reven »

On a technical note, I just used VC++ 2008 Express to build bzflag, and I found that the latest DirectX SDK no longer ships with dinput.lib. DirectX runtimes still ship with dinput.dll, however. This means to build bzflag with the latest DX SDK, you just need to find a copy of dinput.lib. I found it by referencing a link in this forum thread. I just copied dinput.lib into the lib folder where the DX SDK installed.

The alternative is to patch bzflag to use the newer DX version 8+ DirectInput interface. I'm not sure if swapping DirectInputCreateEx() for DirectInput8Create() is all you'd need to do. This might be a good idea at some point, since the fact that dinput.lib isn't in the SDK any more is probably a signal of things to come.
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Post by JeffM »

the DirectX SDK from april 2007 is the last one we support. The readme in SVN for our current development line has this documented.
ImageJeffM
Post Reply