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!
how i compiled bzflag-2.0.10 source winxp msvc++8 express
-
- 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
Last edited by SkindupTruk on Fri Jun 06, 2008 5:14 pm, edited 1 time in total.
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.
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.
JeffM
-
- Private First Class
- Posts: 19
- Joined: Fri Apr 11, 2008 10:17 pm
well, that was a terse response.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.
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.
-
- Private First Class
- Posts: 19
- Joined: Fri Apr 11, 2008 10:17 pm
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.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.
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.
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.
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.
"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.
JeffM
Can you quote a reference on that? Microsoft seems to think differently. From the Microsoft Visual Studio Express FAQ: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.
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.Microsoft wrote: 4. Can I use Express Editions for commercial use?
Yes, there are no licensing restrictions for applications built using the Express Editions.
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.
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.