Sophie: asc-1.10.0-1mdk i586

asc-1.10.0-1mdk.i586.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>

<META NAME="Generator" CONTENT="WebWriter/2 v1.2">
<TITLE>ASC documentation: The Source</TITLE>
	<LINK REL="stylesheet" TYPE="text/css" HREF="asc.css">
</HEAD>

<BODY text="#000000" bgcolor="#ffffff">

<CENTER>
<H1>Advanced Strategic Command</H1>
<P>documentation<P>
<H1>The Source</H1>
</CENTER>

<H2>Introduction</H2>


ASC has a long history. The project was start in summer 1994 using Borland Pascal as the programming language. But even then the graphics engine was already available since it was written in 1993 for a simple Tetris clone. 
In 1995 we started using object orientated programming and in 1996 we converted the whole project to C/C++ (Watcom). We started the port to GCC and Linux in 1999. In autumn 2000 the port to Windows was finished and in winter 2000 the DOS version finally dropped, together with support for the Watcom C/C++ compiler (which doesn't support all features of ANSI C++). <p>

Most parts of ASC itself were written by me (Martin Bickel), while Marc Schellenberger wrote the map editor and Alexander Sch&auml;fer wrote the first "small editors".
ASC was the project I learned serious programming with. If you look at the source you will see this, both the technical history with its DOS origins and my progress in designing software. <p>

If I started such a project now from scratch I would design it completely different. But we have the project as it is and it is now a game that can be played really well. So rather than starting from scratch it is better to rewrite only one part at a time. This has several benefits:
<ul>
<li>The game is always playable. 
<li>development on the non-programming areas like graphics, sound, units and maps can be done in parallel and all these data work is simultaneously available to both players and programmers. And it can be tested immediately.
<li>Real testing is only possible in real games, which requires a more or less feature-complete game
<li>ASC already has a very solid and much refined gameplay. 
</ul>

So our goal should be to improve ASC one part at once, with frequent releases to keep the players happy :-) <p>

<p>

Originally we didn't care about source documentation and modularization. We always preferred writing cool new features instead of cleaning up the code :-) <p>

But the ASC project has reached a point were it can no longer be maintained by a single programmer and I myself don't intend to spend my entire life just working on this single project. But since it would be an enourmous loss for humanity if this project would die :-) my primary goal now is to get the source code into such a shape that others can join the development and hopefully, sometime in the future, take the whole project over. <p>
During the last year, I've spend much time to clean up the source, document and modularize it. While the work is not finished and I intend to further work on it, the code should already be much more accessible now. 

<p>
Martin Bickel, October 2001

<H2>Required Tools</H2>

<H3>for building the Windows version</H3>
We are building ASC/win with Borland C++ Builder 5. It should be possible to build ASC with any other Windows compiler too, if it has some sufficient understanding of the C++ language. Microsoft Visual C++ version 6 and older have not, it is absolutely impossible to compile ASC with these primitive compilers. But Visual Studio .NET is much improved and can compile ASC without any problems. The project files for Visual Studio .NET are included in the <tt>asc/source/win32/msvc</tt> directory, although they are not completed yet. But finishing them should be straight forward.

It is also possible to compile ASC with the free <A HREF="http://www.borland.com">Borland</A> command line compiler. Makefiles for it are included <P>

<H4>Borland C++ Builder / free command line compiler</H4>

<OL>
<LI>Get the <A HREF="http://www.asc-hq.org/library_package.zip">Library Package</A>.
<LI>If you downloaded the packaged sourcecode, the directory there is named <TT>asc-1.9.0</tt> or something similar. Rename it to <tt>asc</tt>.
<li>Now uncompress the library package so that its <tt>asc</tt> directory and the <tt>asc</tt> directory of the ASC source overlap.

<H5>Borland C++ Builder</H5>
<OL start=4>
<LI>Open <TT>asc/Asc.bpg</TT> and run "make all projects"
<LI>If you want to run ASC from within Borland C++ Builder, place a file <TT>ASC.INI</TT> in <TT>asc\soure\win32\borland\</TT> that contains the following line: <BR>
<TT>SearchPath0=c:\somewhere\</TT><BR>
replace c:\somewhere by the directory where you want ASC to place its files (savegames, etc.).
<LI>Get the data files (<tt>main.con</tt> and others) from the <A HREF="http://www.asc-hq.org/download.html">website</A> and put it in this directory.
</OL>
<H5>Free Borland C++ command line compiler</H5>
<OL start=4>
<LI>Execute <TT>asc/makebcc.bat</TT> <P>

All major files will be placed in the <TT>asc\game\</TT> directory that is going to be created.
</OL>
</OL>

If you want to recreate the library package or use newer versions of the libraries, read the <A HREF="source_borland.html">detailed installation instructions</a>.

<H3>Microsoft Visual C++ 7.0</H3>

<H4>Environment variables </H4>
The VC++ 7.0 projects use some environment variables to get access to header and lib files not included with the sources of ASC. These variables are for now :
<TT>
<UL>
<LI>SDL
<LI>SDLmm
<LI>SDL_mixer
<LI>SDL_image
</UL>
</TT>

<p>
Set these variables to point to the directories where you installed SDL, SDLmm, SDL_mixer and SDL_image. The projects will search in the following directories to find the header and lib files : <br>

<TABLE border>
<tr>
  <th> Library name </th>
  <th> Include path </th>
  <th> library path </th>
</tr>

<tr>
 <td> <A HREF="http://www.libsdl.org">SDL</A> </TD>
 <td> $(SDL)/include </td>
 <td> $(SDL)/lib </td>
</tr>

<tr>
 <td> <A HREF="http://sdlmm.sf.net">SDLmm</A> </TD>
 <td> $(SDLmm)/src </td>
 <td> $(SDLmm)/lib </td>
</tr>

<tr>
 <td> <A HREF="http://www.libsdl.org/projects/SDL_mixer/index.html">SDL Mixer</A> </TD>
 <td> $(SDL_mixer) </td>
 <td> $(SDL_mixer)/lib </td>
</tr>

<tr>
 <td> <A HREF="http://www.libsdl.org/projects/SDL_image/index.html">SDL Image</A> </TD>
 <td> $(SDL_image) </td>
 <td> $(SDL_image)/lib </td>
</tr>
</TABLE>

<H4>How to compile:</H4>
Get the Jpeg library from the <A HREF="http://www.ijg.org/">Independent JPEG Group</A> and extract them into the <TT>games\asc\source\libs\jpeg-6b</TT> directory.
As soon as all your SDL stuff is ready and the environment variables are set, open the MSVC++ 7.0 solution <TT>games\asc\source\win32\msvc\asc-hq.sln</TT> in MSDev. In the "Solution Explorer", right clic on the project ASC and select "Build".

<H4>How to run ASC:</H4>
Grab the datafile ( main.con ) fom the website and put it in <TT>games\asc\source\Debug\bin</TT> and/or in <TT>games\asc\source\Release\bin </TT>( depending on the debug or release target you selected in MSDev to compile ASC ).
<p>
Double-click on asc.exe in <TT>games\asc\source\Debug\bin</TT> and/or in <TT>games\asc\source\Release\bin</TT> to start the game. Or you can just press CTRL-F5 in MSDev to start the game from the development environment.



<H3>for building the Linux version</H3>
Well, nothing special about that. We build ASC with the standard GNU development tools. Refer to INSTALL for (generic) build instructions.

<H3>Watcom C++</H3>

The discontinued DOS version and early Windows versions of ASC were built with Watcom C/C++ 11.0b. Since the compiler is dead and does not support all ANSI-C++ features, ASC can no longer be build with it.
Just in case that the <A HREF="http://www.openwatcom.org">OpenWatcom-Project</A> will bring the compiler up to date, we preserved the <A HREF="source_watcom.html">build instructions</A> (which are already out of date...).


<H2>Porting ASC</H2>
Porting ASC to any platform supported by SDL should be farely easy (as long as it is 32 bit and has Intel byte order).

Porting ASC to 64 bit or big-endian platforms requires some more work, but nothing that cannot be done in a few days ;-)

<H2>The source documentation</H2>
The source documentation system used for ASC is <A HREF="http://www.stack.nl/~dimitri/doxygen/">doxygen</A> with the doxygen configuration file being <TT>asc/source/doxygen.config</TT>. <p>
You can access either generate the source documentation yourself using doxygen or access it online at <A HREF="http://www.asc-hq.org/sourcedocumentation/index.html">www.asc-hq.org/sourcedocumentation/</A>.


<H2>Source code formatting</H2>
Since there are many different source code formatting styles out there, it would be quite a mess if everybody wanted ASC to have his own style and spended half his time undoing the formatting that others did. I can't and don't want to force everybody to use exactly the same style, but if some source is <B>re</B>formatted, then it should be done to a well defined layout.
<A HREF="http://astyle.sourceforge.net/astyle/">Artistic Style</A> is a capable program for formatting source code.
The settings <TT>--style=linux -s3 -C -S</TT> are recommended to be used for ASC. If you write these settings to a file <TT>~/.astylerc</TT>, you don't need to type them each time you call Astyle. The central setting there is the -s3, which tells Astyle to indent with 3 spaces.<P>

<strong>Some nested and nasty #ifdefs can confuse Astyle. After using Astyle, check the last line of the source file and verify they are correctly indented. If they are not, either fix the #ifdef or restore to the backup file that was created by Astyle!</strong><P>

And here is my personal opinion about line breaks: I don't like breaking each line after 80 characters. The times when that was the upper limit of what a monitor could display at once are long passed. And since the first 120 characters (or whatever you can display on your screen at once) of a command are usually sufficient to get an idea what the command is doing, I prefer to not have the next line cluttered with some coordinate calculations that nobody is really interested in. If one breaks them, they just obstruct the view from the important part (which is the beginning) of the next command.
<P>


</BODY>
</HTML>