Mercurial > sdl-ios-xcode

view Borland.html @ 942:41a59de7f2ed

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Here are patches for SDL12 and SDL_mixer for 4 or 6 channel surround sound on Linux using the Alsa driver. To use them, naturally you need a sound card that will do 4 or 6 channels and probably also a recent version of the Alsa drivers and library. Since the only SDL output driver that knows about surround sound is the Alsa driver, you���ll want to choose it, using: export SDL_AUDIODRIVER=alsa There are no syntactic changes to the programming API. No new library calls, no differences in arguments. There are two semantic changes: (1) For library calls with number of channels as an argument, formerly you could use only 1 or 2 for the number of channels. Now you can also use 4 or 6. (2) The two "left" and "right" arguments to Mix_SetPanning, for the case of 4 or 6 channels, no longer simply control the volumes of the left and right channels. Now the "left" argument is converted to an angle and Mix_SetPosition is called, and the "right" argu- ment is ignored. With two exceptions, so far as I know, the modified SDL12 and SDL_mixer work the same way as the original versions, when opened for 1 or 2 channel output. The two exceptions are bugs which I fixed. Well, the first, anyway, is a bug for sure. When rate conversions up or down by a factor of two are applied (in src/audio/SDL_audiocvt.c), streams with different numbers of channels (that is, mono and stereo) are treated the same way: either each sample is copied or every other sample is omitted. This is ok for mono, but for stereo, it is frames that should be copied or omitted, where by "frame" I mean a portion of the stream containing one sample for each channel. (In the SDL source, confusingly, sometimes frames are called "samples".) So for these rate conversions, stereo streams have to be treated differently, and they are, in my modified version. The other problem that might be characterized as a bug arises when SDL_mixer is passed a multichannel chunk which does not have an integral number of frames. Due to the way the effect_position code loops over frames, when the chunk ends with a partial frame, memory outside the chunk buffer will be accessed. In the case of stereo, it���s possible that because malloc may give more memory than requested, this potential problem never actually causes a segment fault. I don���t know. For 6 channel chunks, I do know, and it does cause segment faults. If SDL_mixer is passed defective chunks and this causes a segment fault, arguably, that���s not a bug in SDL_mixer. Still, whether or not it counts as a bug, it���s easy to protect against, so why not? I added code in mixer.c to discard any partial frame at the end of a chunk. Then what about when SDL or SDL_mixer is opened for 4 or 6 chan- nel output? What happens with the parts of the current library designed for stereo? I don���t know whether I���ve covered all the bases, but I���ve tried: (1) For playing 2 channel waves, or other cases where SDL knows it has to match up a 2 channel source with a 4 or 6 channel output, I���ve added code in SDL_audiocvt.c to make the necessary conversions. (2) For playing midis using timidity, I���ve converted timidity to do 4 or 6 channel output, upon request. (3) For playing mods using mikmod, I put ad hoc code in music.c to convert the stereo output that mikmod produces to 4 or 6 chan- nels. Obviously it would be better to change the mikmod code to mix down into 4 or 6 channels, but I have a hard time following the code in mikmod, so I didn���t do that. (4) For playing mp3s, I put ad hoc code in smpeg to copy channels in the case when 4 or 6 channel output is needed. (5) There seems to be no problem with .ogg files - stereo .oggs can be up converted as .wavs are. (6) The effect_position code in SDL_mixer is now generalized to in- clude the cases of 4 and 6 channel streams. I���ve done a very limited amount of compatibility testing for some of the games using SDL I happen to have. For details, see the file TESTS. I���ve put into a separate archive, Surround-SDL-testfiles.tgz, a couple of 6 channel wave files for testing and a 6 channel ogg file. If you have the right hardware and version of Alsa, you should be able to play the wave files with the Alsa utility aplay (and hear all channels, except maybe lfe, for chan-id.wav, since it���s rather faint). Don���t expect aplay to give good sound, though. There���s something wrong with the current version of aplay. The canyon.ogg file is to test loading of 6 channel oggs. After patching and compiling, you can play it with playmus. (My version of ogg123 will not play it, and I had to patch mplayer to get it to play 6 channel oggs.) Greg Lee <greg@ling.lll.hawaii.edu> Thus, July 1, 2004
author Sam Lantinga <slouken@libsdl.org>
date Sat, 21 Aug 2004 12:27:02 +0000
parents de622b7108bf
children
line wrap: on
line source

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Building SDL with Borland's C++ compilers</title>
                                  
  <meta name="author"
 content="David Snopek and updated by Dominique Louis.">
</head>
  <body>
     <xevol @newtonave.net="">      </xevol>     
<h1>Building SDL with Borland's C++ compilers. </h1>
      <b> by <a href="mailto:xevol@users.sourceforge.net"> David Snopek</a></b> 
    and updated by <b><a href="mailto:Dominique@SavageSoftware.com.au">Dominique 
  Louis</a></b> ( Last updated : 30th June 2003 ).<br>
      <br>
       These instructions cover how to compile SDL and its included test
programs   using either  Borland <a href="#bcbwin">C++ Builder 5, 6 for Windows</a>, 
 <a href="#k3">C++ Builder for Linux  ( AKA Kylix 3 )</a> or the free <a
 href="#bccc">Borland C++ command-line compiler</a>. <br>
            
<h3> <b> Extract the files </b> </h3>
            
<p> Unzip the Borland.zip archive into <b>this</b> directory.  Do not unzip 
  it into any  other directory because the makefiles ( *.mak ) and project 
 files ( *.bpr ) use relative paths to refer to the SDL sources.  This  should 
 create a directory named "Borland" inside of the top level SDL source directory. 
   </p>
            
<h3> <b><a name="bcbwin"></a> Using Borland C++ Builder 5, 6 for Windows </b>
</h3>
            
<p> Inside of the "Borland" directory there is a "bcb6" directory that contains 
  a number  of Builder project files.  Double-click on the "libSDL.bpg" file 
  icon.  Once Builder has  started click on the "<u>P</u>rojects" menu on 
the  menu-bar and go down to  "B<u>u</u>ild All Projects" option.  <br>
   This will proceed  to build SDL ( with Borland's calling convention ), 
SDLmain,  and all  the <a href="#tests">test programs</a>. Currently, all 
the <a href="#tests">test programs</a>  are dynamically linked to Sam Lantinga's 
SDL.dll.</p>
     
<p><b>NOTE :</b> Borland's "lib" format and Microsoft's "lib" format are incompatible.
&nbsp;<br>
   If you wish to dynamically link to the SDL library supplied by Sam Lantinga 
 in each release, I have created the correct *.libs for SDL 1.2.4 and they 
 exist in the "/lib" directory.<br>
   If you would like to create the *.lib files yourself, you will need to 
make  use of Borland's "implib.exe" utility.<br>
   </p>
     
<p><tt>IMPLIB</tt> works like this: </p>
       
<pre>    IMPLIB (destination lib name) (source dll)<br></pre>
       
<p> For example,</p>
       
<pre>    IMPLIB SDL.lib SDL.dll<br></pre>
     
<p>This assumes that SDL.dll was compiled with Visual C++ or similar.<br>
   </p>
     
<p>To learn more about the difference between Borland's and Microsoft's *.lib 
 format please read the article <a
 href="http://www.bcbdev.com/articles/vcdll.htm">here</a>.<br>
   </p>
     
<p>  <b><br>
   NOTE :</b> The C++ Builder for Windows project format, is not compatible
 with the Kylix  3 project format, hence the reason why they are in separate
 directories.</p>
            
<h3> <b><a name="bccc"></a> Using the free Borland C++ command-line compiler 
 </b> </h3>
            
<p> The free Borland compiler can be downloaded at no charge from <a
 href="http://www.borland.com/bcppbuilder/freecompiler/"> the  Borland website 
  </a>.  Make sure that it is installed and properly configured. </p>
            
<p> Open an MS-DOS Prompt.  Change to the "Borland\freebcc" directory under 
  the  SDL source directory.  Type "make -f SDL.mak" to build SDL and "make 
  -f  SDLmain.mak".  There are also makefiles for all of the <a
 href="#tests">test  programs</a>, if you wish to build them. All .exes and 
DLLs are created in the "test" SDL directory. Ify ou would like to create 
the DLL and all the test applications, I have thrown together a basic batchfile 
called "makeall.bat" which should create everything in the right order. </p>
            
<h3> <b> Output files </b> </h3>
       No matter which compiler you used, three important files should have 
 been  produced:        
<ul>
      	<li> SDL.dll ( Borland format ) </li>
      	<li> SDL.lib&nbsp;( Borland format ) </li>
      	<li> SDLmain.lib&nbsp;( Borland format ) </li>
           
</ul>
       Both of the *.lib files will need to be added to all the projects
that   use SDL and SDL.dll  must be placed some where the Windows dynamic
linker   can find it (either in your  project directory or on the system
path, C:\WINDOWS\SYSTEM).       
<h3> <b><a name="k3"></a> Using Borland C++ Builder for Linux ( AKA Kylix 
 3 ) </b> </h3>
              
<p> Inside of the "Borland" directory there is a "k3" directory that contains 
  a number  of Builder project files.  Double-click on the "libSDL.bpg" file 
  icon.  Once Builder has  started click on the "<u>P</u>rojects" menu on 
the  menu-bar and go down to  "B<u>u</u>ild All Projects" option.  This will 
proceed  to build all  the <a href="#tests">test programs</a>.&nbsp;<br>
   Linux  users do not need *.lib files as the Shared Object is linked right 
 into the  project ( very neat actually, Windows should do this sort of thing 
 as it is a lot easier for the developer ).  <br>
      <b>NOTE :</b>&nbsp;The C++ Builder for Windows project format, is not
 compatible with the Kylix  3 project format, hence the reason why they are
 in separate directories.</p>
           
<p> On Mandrake 8.1 the shared objects for SDL are located in the /usr/lib 
  directory as libSDL_*.so and the Mesa OpenGL shared objects are located 
in  /usr/X11R6/lib as libGL*.so<br>
       <br>
       So if your setup is different you may need to change the project file
  so that they re-link to the ones on your system.<br>
       <br>
       On Mandrake 8.1 the headers files are located at /usr/include/SDL/.
 So  if you you have not installed the development RPMs ( usually named libSDL-devel*
   ) for SDL ( not included ) you may have to change the include directory
 within  some of the projects.<br>
   </p>
     
<h3> Known Problems</h3>
     The only known problem is that I ( Dominique Louis ), was unable to
create  the projects that rebuilt the SDL shared objects under Linux, due
to time  constraints and my lack of intimate knowledge of Linux.     
<h3><a name="tests"><b> Test programs </b> </a></h3>
   Some of the test programs require included media files ( *.wav; *.bmp
etc   ). All the test programs are now created in the "test" directory, where
the media files are ( usually ) so they should be ready to go.  <br>
     <br>
  <br>
 <br>
</body>
</html>