mirror of
https://git.code.sf.net/p/quake/quakeforge
synced 2025-02-17 01:11:45 +00:00
No description
bd98d1d9fb
So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side. |
||
|---|---|---|
| config.d | ||
| debian | ||
| desktop | ||
| doc | ||
| hw | ||
| include | ||
| libs | ||
| m4 | ||
| nq | ||
| pkg-config | ||
| qtv | ||
| qw | ||
| RPM | ||
| ruamoko | ||
| tools | ||
| vc2005 | ||
| vc2008 | ||
| .gitignore | ||
| bootstrap | ||
| configure.ac | ||
| COPYING | ||
| INSTALL | ||
| Makefile.am | ||
| NEWS | ||
| README.cygwin | ||
| TODO | ||
This file gives instruction for compiling QF with cygwin to run in MS Windows(R).
DISCLAIMER: Use at your own risk, NO WARRANTY of any kind. NO GUARANTEE of correctness or usability.
If you have problems with these instructions please let me know.
email: wildcode@users.sourceforge.net
IRC: irc.xiph.org #quakeforge
==========================================================================
WARNING: This is not intended for inexperienced users, binaries are available on request.
QuakeForge may take several hours from bootstrap to the completion
of make install on some systems
To build win32(mingw) QuakeForge bins you will need to download and install cygwin, and the Microsoft DirectX SDK. Cygwin can be found at http://www.cygwin.org
Once cygwin is installed along with the appropriate developement modules, copy dinput.h from the DirectX SDK and place it in /usr/include/w32api/
If you want to use DirectSound also copy dsound.h to the same spot.
in the quakeforge source dir, within cygwin, type
./bootstrap
./configure --host=i386-mingw32 --build=i386-cygwin --target=i386-mingw32 --program-prefix= --with-static-plugins --disable-shared --disable-oss --disable-vorbis --disable-Werror --enable-optimize --enable-asmopt --disable-debug --enable-zlib
make
make install
--disable-Werror is needed as some versions of the DX SDK are buggy.
Go to the /usr/local/bin directory and copy the qw-* and nq-* files to your dos
quake dir
Let us know how it works for you.
NOTE: At the time of writing qw-server.exe was not working correctly. Please refrain from using it unless you are willing to fix it.
Special Note: QuakeForge supplies only our own version of the programs for Quake. To get the game data, you still need to have purchased Quake or get the shareware version from Id Software.
Chris Ison (WildCode) for QuakeForge
March 11, 2003