Mercurial > sdl-ios-xcode
view Borland.html @ 563:04dcaf3da918
Massive Quartz input enhancements from Darrell Walisser. His email:
Enclosed is a patch that addresses the following:
--Various minor cleanups.
Removed dead/obsolete code, made some style cleanups
--Mouse Events
Now keep track of what button(s) were pressed so we know when to send
the mouse up event. This fixes the case where the mouse is dragged
outside of the game window and released (in which case we want to send
the mouse up event even though the mouse is outside the game window).
--Input Grabbing
Here is my take on the grabbing situation, which is the basis for the
new implementation.
There are 3 grab states, ungrabbed (UG), visible (VG), and invisible
(IG). Both VG and IG keep the mouse constrained to the window and
produce relative motion events. In VG the cursor is visible (duh), in
IG it is not. In VG, absolute motion events also work.
There are 6 actions that can affect grabbing:
1. Set Fullscreen/Window (F/W). In fullscreen, a visible grab should do
nothing. However, a fullscreen visible grab can be treated just like a
windowed visible grab, which is what I have done to help simplify
things.
2. Cursor hide/show (H/S). If the cursor is hidden when grabbing, the
grab is an invisible grab. If the cursor is visible, the grab should
just constrain the mouse to the window.
3. Input grab/ungrab(G/U). If grabbed, the cursor should be confined to
the window as should the keyboard input. On Mac OS X, the keyboard
input is implicitly grabbed by confining the cursor, except for
command-tab which can switch away from the application. Should the
window come to the foreground if the application is deactivated and
grab input is called? This isn't necessary in this implementation
because the grab state will be asserted upon activation.
Using my notation, these are all the cases that need to be handled
(state + action = new state).
UG+U = UG
UG+G = VG or IG, if cursor is visible or not
UG+H = UG
UG+S = UG
VG+U = UG
VG+G = VG
VG+H = IG
VG+S = VG
IG+U = UG
IG+G = IG
IG+H = IG
IG+S = VG
The cases that result in the same state can be ignored in the code,
which cuts it down to just 5 cases.
Another issue is what happens when the app loses/gains input focus from
deactivate/activate or iconify/deiconify. I think that if input focus
is ever lost (outside of SDL's control), the grab state should be
suspended and the cursor should become visible and active again. When
regained, the cursor should reappear in its original location and/or
grab state. This way, when reactivating the cursor is still in the same
position as before so apps shouldn't get confused when the next motion
event comes in. This is what I've done in this patch.
author | Ryan C. Gordon <icculus@icculus.org> |
---|---|
date | Fri, 27 Dec 2002 20:52:41 +0000 |
parents | 25f475cd4981 |
children | de622b7108bf |
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>.<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. <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. </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 ( Borland format ) </li> <li> SDLmain.lib ( 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>. <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> 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 ). Before trying to run any of the test programs, copy these media files from the "tests/" directory into the Borland build directory that you extracted the project files to. <br> <br> </body> </html>