// "Build Engine & Tools" Copyright (c) 1993-1997 Ken Silverman // Ken Silverman's official web site: "http://www.advsys.net/ken" // See the included license file "BUILDLIC.TXT" for license info. /* * README. * * Please do NOT harrass Ken Silverman about any code modifications * (including this file) to BUILD. */ (This code DOES run on Windows. Read on.) For building on Linux, you NEED gcc 2.95.2 (or maybe later) to compile this code correctly. You'll also need Netwide Assembler (NASM). Get it at: http://www.kernel.org/pub/software/devel/nasm/ (May I reiterate? Earlier than 2.95.2 revisions of GCC and EGCS do NOT compile this code correctly! It will run, but there will be all sorts of strange graphic glitches and odd crashes.) For building on Win32, you need Watcom C v11.0. With the Win32 target (Perhaps they call it the "NT" target?) installed. You can maybe get by with Watcom C version 10.x, but the binaries tend not to work on WinNT in that case. You can also compile the code on Win32 with Cygwin and NASM. Read below for more details in either case. For building under DOS, you need Watcom C v11 or v10 with the DOS target installed. This code uses Simple Directmedia Layer (SDL) for graphics, sound, and other platform abstractions. Build relies on a fairly recent SDL code snapshot. Get SDL from CVS like this: cvs -d :pserver:guest@cvs.lokigames.com:/cvs login # password is "guest", without the quotes. cvs -z3 -d :pserver:guest@cvs.lokigames.com:/cvs checkout SDL12 cd SDL12; ./autogen.sh; make; make install CVS is also good if you want the up-to-the-minute changes of BUILD: cvs -z3 -d:pserver:anonymous@icculus.org:/cvs/cvsroot login # password is "anonymous", without the quotes. cvs -z3 -d:anonymous@icculus.org:/cvs/cvsroot co buildengine There is a win32 CVS client available for download here: http://www.icculus.org/misc/cvs-over-ssh-win32.zip You can get more information about CVS from http://cvshome.org/ ... PLEASE READ THE CHANGELOG AND TODO FILE FOR DETAILS ON WHAT'S NEW AND WHAT'S NEEDED! They're in the tarball. Have fun! --ryan. (icculus@icculus.org) INFO: - Patches go to Ryan at icculus@icculus.org. - Please try to keep it so the original source can still be compiled with Watcom C for DOS. Maybe if we do a good enough job, we can just get Ken to make this his official version, although this is not the goal right now. You may #ifdef DOSisms with PLATFORM_DOS, and Unixism with PLATFORM_UNIX, but try not to touch the original code if you can circumvent it (i.e. reimplement the functionality of missing functions in a separate file, #define __interrupt to be blank, etc...) Reference unix_compat.[ch] and sdl_driver.c for examples of this behaviour. - See us in #loki at irc.openprojects.net with questions. - This is NOT a Loki-sponsored project. We are (er...WERE) Loki employees that get off on this stuff. Don't harrass info@lokigames.com about it. - Yes, you CAN edit Duke3D maps with this. Sort of. Find your DUKE3D.GRP file, and set this environment variable: (on Windows: "set BUILD_GROUPFILE=C:\where\grpfile\is\DUKE3D.GRP") (on Linux/bash: "export BUILD_GROUPFILE=/where/grpfile/is/DUKE3D.GRP") Without this environment variable, Build looks for "stuff.dat" in the current directory; that's KenBuild's groupfile. Now go get a Duke3D map off the net and open it in build. I haven't tried Blood, Shadow Warrior, or anything else, but someone sent me screenshots of Shadow Warrior. Your mileage may vary. Either way, there's lots of screenshots up at: http://www.icculus.org/BUILD/screenshots/duke3d_data_files/ http://www.icculus.org/BUILD/screenshots/shadow_warrior_data_files/ There is still much missing from Build that is needed to use it as a Duke3D editor, and that is not the focus of this project. It is DEFINITELY not enough to PLAY duke3d, as there is no CON interpreter or correct physics or enemy AI or equivilent sector tags etc. If an editor is all you want, there is a project called Mapster (http://mapster-rtcm.totalconversions.com/) that is a KenBuild source modification to support all of DukeBUILD's features, and add some new enhancements, too. Stay tuned, as there may be a win32 (and Linux?) version of Mapster sooner or later. In short, is this enough to play Duke/Shadow/Blood? No. But it's a good start. - Can Windows users use this code? You bet. Binaries available. - To build this from source under Windows: You can use Cygwin, a Windows port of the GNU C compiler. Cygwin is free (as in speech and beer), and can be downloaded from http://sources.redhat.com/cygwin/. You will also need to have a development version of SDL installed (I used the prebuilt SDL libraries under Windows, look at http://www.libsdl.org/). And, as under Linux, you will need NASM (http://www.kernel.org/pub/software/devel/nasm/). Make sure nasmw.exe ends up somewhere in your PATH, and SDL is somewhere you have access to. Once you have all this set up, unpack the BUILD sources. Make sure you're in the buildengine directory. Set these two environment variables: export SDL_LIB_DIR=C:/where/i/installed/SDL-1.2.0/lib export SDL_INC_DIR=C:/where/i/installed/SDL-1.2.0/include (Yes, those directory separators are backwards; it is intentional.) ...then, type "make", and it should produce binaries for you if you did everything right. You will have to make sure that SDL.DLL and CYGWIN1.DLL are in your path somewhere. This isn't all as hard as it sounds. :) - To build with Watcom C for Win32: Get SDL (as above). Unpack the source, edit Makefile.w32 (instructions are in that file). Change the paths at the top to point to your Watcom and SDL installs. Run "wmake -f Makefile.w32" ... that's all. I tried this with Watcom C 10.6 and 11.0 using the win32 (both "nt" and "nt_win") targets. Anything older than Watcom C 11.0 will NOT build an EXE that will work on Windows NT 4.0 or Windows 2000, even though the same binary will work on Windows 95 and 98. Your mileage may vary. - If anyone wants to make this work with Visual C++ to make this easier for Windows users, I'll happily accept your changes and additions. - One more thing, about licensing. If you build this with Cygwin, you are NOT permitted to release binaries, as Cygwin's POSIX-support DLL is under the GPL license, which forbids distribution of code linked with it that doesn't abide by the OpenSource definition (Ken's license does not). Harrassing Ken Silverman to change his license to the GPL is not only rude, it's unproductive. Distributing binaries built with Cygwin opens you up to lawsuits from Red Hat and the Free Software Foundation. Do the right thing; if you must distribute BUILD binaries, don't build them with Cygwin. - Does this code still work under DOS? Yup. You use Watcom C the same as you would for the Windows target, except you use Makefile.dos. Note that the Windows and Linux versions are better maintained, more stable, and support more hardware. Don't ask Ken about the DOS port either. He probably wouldn't recognize his own code after all the mangling we did. :) - Wish your GRP files weren't so big? Convert them to PkZip format, build the engine with PhysicsFS support, and set the environment variable BUILD_GROUPFILE=mygroupfile.zip ... Look at PhysicsFS's homepage for more information: http://www.icculus.org/physfs/ ... GOOD REFERENCES: - VESA i/o reference: http://pm.cse.rmit.edu.au/~steve/vbe/vbe20.htm - http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html (THE Interrupt List, from Ralf Brown. Good stuff, here.) - FreeVGA: A VGA documentation project. http://www.goodnet.com/~tinara/FreeVGA/home.htm - BUILD keyboard reference: http://home.online.no/~flovstak/duke/bkeys.htm - mapFAQ: http://mapfaq.3dportal.com/ - Ken Silverman's homepage: http://www.advsys.net/ken/ - The Art of Assembly Language, complete text: http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/ArtofAsm.html HOW TO FIX ALL YOUR "//" COMMENTS: - We now compile BUILD with the most anal compiler settings available for any given platform. This forces us to write cleaner, more portable, and less buggy code, but sometimes it limits what we can get away with. Most notably: comment syntax. There are some compilers on some platforms (*coughcoughSolariscoughcough*) that are very anal about (the old version of) the C specification they follow. Therefore, you can NOT use "//" single line comments in code compiled on those toolchains. Since Ken used nothing but // comments, I needed to automate the conversion process a little bit. Here's the quick and dirty way to convert them, using Perl: --- snip. --- while () { chomp; s/(.*)(? myconvertedsrc.c (patches to that code are welcome.) TO PORT TO NEW COMPILERS AND TOOLCHAINS: - Try to get nasm to generate object files that your linker can understand. That is the easiest for the asm modules. Use a_nasm.asm, which is the NASM version. a.asm is the Watcom Assembler (wasm) version that Ken distributed with the original Build source release. - The alternative is to write portable C code to avoid all the self-modifying ASM. Have the appropriate amount of fun. - There is inline assembly in engine.c, game.c, pragmas.c, and pragmas.h. Every compiler has their own syntax for this. Have more fun. - Try to find clean syntax fixes that work everywhere instead of #ifdef'ing, if you can. Platform.h is a good starting point. TO PORT TO NEW OPERATING SYSTEMS: - If Simple Directmedia Layer supports your OS, you're in luck. Just get everything building (see above). If not, look at display.h for what you need to implement, and sdl_driver.c and dos_drvr.c for examples. Consider getting SDL working on your platform instead. - Your platform needs at least an 8-bit linear framebuffer for video. Otherwise, you can pray the OpenGL code gets written and is useful to you. - The code doesn't necessarily NEED a keyboard, but the input device has GOT to have a lot of buttons. The renderer itself doesn't deal with input, just the apps (build, game, duke3d) that use it, so this may not be a problem, depending on your needs. Some apps (the editor itself, for example) seem to demand a mouse. - Your platform needs to be 32-bit clean, in all likelihood. You might be able to make enough band-aids to get this working otherwise. No one's tried it on a 64-bit platform yet, partially due to all the (32-bit) assembly code. 16-bits or less will likely be a nightmare. - Start in platform.h for an idea of where to add anything that's platform-specific. If you can't get by on PLATFORM_UNIX, then define PLATFORM_WHATEVER. - Try not to wedge in platform dependent code, but find good abstractions. TO PORT TO NEW PROCESSORS: - You can either write new ASM for your processor, or better yet, implement the stuff in portable C, so everyone can benefit. - Most of your work will be in pragmas.*, a_linux.*, and a.*. Look for USE_I386_ASM. Define your own version. /* end of README ... */