@database "ADescent.guide" @author "Hans-Joerg Frieden,Thomas Frieden" @remark "$VER: ADescent Guide 1.6 (31-Mar-1998)" @remark "$Id: ADescent.guide,v 1.6 1998/04/07 21:42:53 hfrieden Exp $" @remark "$Revision: 1.6 $" @node MAIN "Welcome to ADescent" Hello and Welcome to the 0.7 release of ADescent. Here's a list of what is available in this database: @{"A short Introduction " link introduction} The essential reading @{"What's New " link news } For those that can't wait @{"Requirements " link requirements} What you'll need @{"Features " link features } What it offers @{"Starting ADescent " link starting } How to get it going @{"The ViRGE Version " link virge } About the CV64/3D version @{"Bugs " link bugs } What is broken @{"Hints'n'Tips " link hints } Things you might try @{"History " link history } What has been done before @{"Future " link future } What might be done @{"Author and Copyright " link author } Who's done this @{"ADescent Mini-FAQ " link faq } Frequently asked questions @endnode @node faq "ADescent Mini-FAQ" Here, we want to give answers to some questions and solutions to some problems that we know of. @{b}I try to run ADescent, but it won`t work:@{ub} You may want to try with a clean system, e.g. break into startup-sequence and run all drivers you @{b}must@{ub} have (e.g. Monitors, p96/cgx stuff, ahi). Then try it. You may also try the -noicon switch, or check which options are reported after starting (You may have FPU enabled even though you don`t have one). Also, check if you`ve got the latest ixemul.library. If you still don`t get it to run, @{"contact" link author} us. @{b}When will you make a PPC version:@{ub} I don`t have a PPC, which means there will be no PPC version from us. Sorry. @{b}What`s this not enough strings message:@{ub} If you get this message when you start up ADescent, it means that you have a pre-1.5 .HOG file. The newer versions all had some more messages in the game, and these are missing from the 1.0 version. The only solution to this is to upgrade your 1.0 files to 1.5. This is normally done on a PC. There are reports that it can be done on a PC emulator. @{b}I get a "Couldn`t open descent.sng", but my .HOG is 1.5:@{ub} You`ve probably got a Macintosh version of the .HOG . The Mac had no MIDI sounds, it played it`s music directly from CD. The only possible solution is to try the @{b}-nosongs@{ub} switch, and proceed with fingers crossed. Another possibility is to @{i}touch descent.sng@{ui} in your ADescent directory (or somehow create an empty file). @{b}I get no sound when playing ADescent:@{ub} There are several possibilities: First, make sure that you have the newest version of AHI installed. You may also check if you`ve installed sound drivers for soundcards you do not have. Another possibility is to check your volume level in the options menu. For more information, look in @{"Hints`n`Tips" link hints}. @{b}I can`t save, or some keys do not seem to work:@{ub} You may have a commodity that eats up keystrokes. Try to remove that. @{b}I run ADescent, but it`s too slow, even on my 060:@{ub} On an 060, you may want to try the @{b}-fpu@{ub} switch. The integer math functions all use instructions that are not available on the 060, so they are implemented with illegal instruction exceptions. This makes it around two to three times slower on the 060. For reference: When starting the first level, I get 17 fps, on an 060 with CyberVision3d, @{b}-fpu@{ub} and @{b}-vdirect@{ub}. Your figures may vary, but it should be around this. @{b}Ok, but what about the 040:@{ub} We`ve got reports from users who tried with and without the @{b}-fpu@{ub} switch on the 040, with different results. For some, it was faster, others said it was slower. Just try for yourself. @{b}I got Picasso96, and -vdirect doesn`t seem to work:@{ub} Yup. It doesn`t. I don`t know why. We are working on it. As some sort of consolidation, the @{b}-wbmode@{ub} switch does not work on CyberGraphX, only on Picasso96, due to a bug in CyberGraphX` WriteLUTPixelArray. Expect both of these bugs to be fixed in later version. @{b}Is ADescent faster on CyberGraphX:@{ub} Yes, we`ve got some reports about this. It seems that it`s sometimes faster on CyberGraphX than on Picasso96. I can`t confirm this yet, but it has been reported. @{b}I try to run the ViRGE binary, but it says "Unable to allocate transparent dummy texture". What does that mean?@{ub} Make sure you have the MULTIMEDIAMEM ToolType in your Devs:Monitors/CVision3D set to YES. This error message is an indication that the program was unable to allocate textures. Since as of V2.10 of the cgx3dvirgin.library there is no "out of memory" error for texture allocation, you must have switched it off completely. @{b}ADescent ViRGE crashes when I switch back to workbench during gameplay@{ub} Make sure that DRAGGING=YES is set in the ToolType of your monitor driver. Due to a problem with the LockView call of cgx3dvirgin.library, the chip might hang if there's activity on another screen. @{b}What is that stuff on my WB Screen when I switch back while playing the ViRGE version? @{ub} That's due to the fact that the ViRGE version writes directly into display memory without protection. I know I should be ashamed about that, but I have to do masked blits to get the text and explosions and other stuff into the screen, and that's not possible with standard ViRGE lib calls, and too slow if I use system functions. After all, the internal structure of Descent is 8 bit LUT format, and I have to convert that to 15 bpp on-the-fly. @{b}The top line of the screen has garbage in it in ADescent_ViRGE@{ub} Yes, shit happens. In this case it happens because I don't delete the screen on every frame. The polygons drawn by the chip stop one line earlier. Might get fixed, but that's not top priority. @{b}Why do the dials and gauges of the HUD and some of the powerup keep vanishing in the ViRGE version?@{ub} As I already pointed out on usenet, the ViRGE chip works @{i}parallel@{ui} to the main CPU. The result is that sometimes I start to draw stuff when the chip hasn't finished working, and it simply overdraws what I've just painted. Man, and some folks didn't believe that the chip can work in parallel... @{b}Why do the textures on the ViRGE chip warp so much more than on the normal version?@{ub} That's because they are decomposed into triangles. The normal mapper draws scanlines, and the ViRGE draw triangle scanlines. The net result is that the u/v-coordinates, when clipped, are correctly interpolated (with perspective in mind), so that you are essentially looking at a subdivision with too few subdivision steps. You might see a similar effect in Quake when you are very close to a wall, since it "only" corrects perspective every 16 pixels. @{b}Why does perspective-corrected texture mapping on the ViRGE look so queer? Can the ViRGE really do p-correct mapping?@{ub} Yes it can. The problem seems to be that it can only wrap a texture once when in p-correct mode. When it reaches the edge of the texture, it just stays on the texel. We hope to fix this. A program that was written with the ViRGE in mind could easily support p-correct mapping. @endnode @node introduction "A Short Introduction" In the beginning there was Doom. Next came Descent. Parallax has finally released the source code to their great game that was in the top ten of the most frequently downloaded games of all times. As soon as the source code became available, we started our port. It is based on the linux source code as done by Patrik McCarthy. This version had all assembly removed, and compiled without too much work with GCC. To get it to actually @{b}@{i}do@{ui}@{ub} something was a completely different story. At present we compile with EGCS. This gives much better code. For those that never played the game, you take the role of the @{b}@{u}Material Defender@{uu}@{ub}, a person responsible for cleaning up the solar system mines of the PTMC corporation. For this purpose, you are equipped with a small one-man spacecraft small enough to navigate through the narrow corridors of the mine. In each mine, you'll have to gain access and destroy the main reactor core of the mine. To make things a bit more tasty, there's someone there that is trying to stop you. @endnode @node news "What's new" (For older news, look in the @{"History" link history} section.) @{FG shine}New for 0.7:@{FG text} - Bugfixes: The automapper bug @{b}should@{ub} be fixed now. - Two player support. You can now play via serial link or internet. Note, though, that the serial link option seems to hang from time to time. This problem is not present in the internet version. - Kali support (Highly experimental). Kali is a system to wrap ipx into internet packets. It is used by some internet servers to allow playing ipx games on the internet (Doom, Descent (I/II), Warcraft). The code in ADescent was done by Arne de Bruijn for the Linux version, and is used with his kind permission. @endnode @node requirements "Requirements" Descent is not the game for the weak processor. You should at least have a 030/50, but a 040 or 060 would be better. PowerPC is currently not supported, but you'll never know... ADescent supports AGA, ECS or CyberGraphX. Picasso96 should also work, but we have reports that the @{b}-vdirect@{ub} option (see @{"Starting ADescent" link starting}) might not work with Picasso96. We are currently investigating. You'll also need a commercial Descent I HOG and PIG file, which should be at least version 1.5 (1.4 might also work), and it should be a PC version. If you have a MAC version, try the @{b}-nosongs@{ub} command line switch. See @{"Obtaining the files" link obtaining} for infos on how to obtain these files. You must have AHI V4 installed, ADescent won't work without. You OS version must be 3.0 or better. You will need about 10 MB of memory, slightly more for the ViRGE version. Might work with VMM, but will obviously slow if it does. For Head-to-Head play, you need a 7-wire null-modem cable (same as for doom), and AmiTCP (Version 3 or later) for internet play. @endnode @node obtaining "Obtaining the data files" There are numerous ways for obtaining the HOG and PIG files. The most obvious (and the only legal way) is buying the game. It is still available on collections, and might have been on some cover CD from a magazine. In Germany, there's the possibility to buy it on the blackmarket label. You might also convince a PC friend to part with the CD/disks, since there's Descent II and Forsaken available there... @endnode @node features "Features" ADescent supports the following features: o Variable graphics modes, including AGA/ECS and CyberGraphX/P96 cards. To get a screen mode requester, start with @{b}-smr@{ub}. Custom C2P code for AGA. Correct aspect even on non-square screen mode (320x400). You may even play in a window on the workbench (well, sort of, at least). o Digital Sound Effects, with full volume and stereo panning. Music isn't yet in it, as I have problems finding info about the HMP/HMQ music format. Also see the @{"Hints'n'Tips" link hints} section on how to configure ADescent for AHI. o Fully multitasking. o Support for Analog Joysticks. This includes normal two-button sticks, four-button sticks and CH FlightStick compatible devices. For the latter two, a special adaptor is requires (see our web page). With FlighStick, ADescent supports all four buttons as well as the "hat", but no thrust lever (might come in the future). o Mouse support (not available in the ViRGE version, sorry). All three buttons are supported. o Amiga'ized Keyboard. Knows almost all keys, including Amiga keys. Pause key is mapped to HELP. Pressing CTRL-ALT-PAD* makes a screen shot (screenxx.pcx). 'PAD*' means that this is the star on the numerical pad (sorry, A600 users). o Fully customizable controls. Controls are saved with your pilot record. o FPU support, 64 bit arithmetics for 040, and much inline assembly now. The texture mapper is assembly now, too. No perspective correction yet, expect this for 0.6^H^H^H0.7 o Workbench startup and icon tooltype parsing. ToolTypes are specified like the command line options without the leading dash, for example -verbose becomes VERBOSE. Options like -option become OPTION=. Icon tooltypes are parsed even when started from shell (ADescent prints the options in effect), using -@{b}noicon@{ub} as the very first argument inhibits tooltype parsing. Tooltypes may be commented out with '*', '(', '<' or '«', i.e the entries (VERBOSE), *VERBOSE, or «NewIcon by... are not parsed. NOTE: IMG1 and IMG2 from the NewIcon system are also not parsed. This caused EMT Trap errors on the first release of the ViRGE version. o Hardware-Accelerated automapper in the ViRGE version. Hardware-assisted texture mapping on CyberVision/3D cards via the ViRGE chip (available in a special archive). o Experimental IPX support, using AmIPX library. This is in no way tested, and might or might not work. We'd like to hear if someone got this to work correctly. @endnode @node starting "Starting ADescent" ADescent might be started either from the Shell or from its icon. In either case, Command line options are parsed first, then icon tooltypes. ToolTypes are always parsed, even when started from Shell... Arguments on the shell command line are specified with a leading dash character, like "-verbose", and if they have an optional parameter, this is specified as "-texcache 50". The same options in the icon would look like: VERBOSE TEXCACHE=50 Capitalization does not really matter, and is done purely for Amiga conventions. Tool types might be commented with '*', '(', '<' or '«'. @{"Installation " link installation} @{"Command line Options" link options} @{"Configuration file " link config} @endnode @node options "Command line options" The following options are supported: @{b}noicon@{ub} Ignore settings from the icon. This must appear as the first argument after the program name on the command line, or it has no effect. @{b}320x400@{ub} @{b}640x480@{ub} Select a different screen size for the game. Not really recommended on the native version, but 320x400 is playable on the ViRGE version. @{b}WBMode@{ub} Do not open a new screen, open ADescent`s window on the workbench screen. This option is only available in direct color modes, i.e. 16/24 bit. Please note that at the moment, this option only works on Picasso96, not on CyberGraphX. @{b}AutoDemo@{ub} Directly goes into demo mode and plays every available demo in the current directory. @{b}FPU@{ub} Use FPU for math functions. Normally, ADescent uses 64 bit operations suitable for 68o3o use as a default. The @{b}-fpu@{ub} switch replaces those with optimized version for 68o4o/68o6o CPU's @{b}FPSLimit @{ub} Only applicable for the ViRGE version. Limits the frame rate to the specified amount. See the @{"ViRGE In-Game menu" link virge_ingame} section for further details. @{b}LargeMap@{ub} Opens the automapper in 640x480-Mode. This will result in a bigger display, but will be slower. Useful for those that don't have, or don't want to define, a 320x400 screenmode. NOTE: When the game asks you for a 320x400-Mode, you should still select this. Using @{b}LargeMap@{ub} specifically requests a 640x480 mode. @{b}LightFX@{ub} Only applicable for the ViRGE version. With this option turned on, you will get the color flashes from the original version back. Since the ViRGE version uses 15 bpp, this isn't done by setting the palette. Instead, it colorizes the lighting of the mine around you. There's really no reason not to include this option. It also shows what it would have looked like if the game originally suported colored light. @{b}Mapper@{ub} Selects the texture mapper to use. Currently only applicable for the ViRGE version. Three modes are available: FPU - Uses Sub-Pixel linear texture mapping. Use this for optimal results. @{FG shine}Requires@{FG text} an FPU INT - Uses normal integer coordinates and linear mapping. (Default) FPUP - Uses Sub-Pixel perspective-corrected mapping. This is the best mapping you would be able to get if it would work. See the section @{"ViRGE In-Game options" link virge_ingame} for an explanation why this does not work as expected. @{b}Network@{ub} Enables experimental IPX support. This used to be the @{b}NoNetwork@{ub} options, but we changed this, since the code is still experimental. @{b}NoConfig@{ub} Do not save the config file at the end of the game. Not really useful, but might be if/when other Descent ports start adding own config items. @{b}NoFilter@{ub} Do not turn on bilinear filtering in the ViRGE version by default. If ommited, filtering is active, but still can be disabled in the game. @{b}NoMouse@{ub} Disables the mouse support. This is the default on the ViRGE version. @{b}NoScreens@{ub} Disables the briefing screens @{b}NoSongs@{ub} Experimential. If ADescent exits with "can't open SONGS.SNG", you might try this option. Untested, so might not help... @{b}NoSound@{ub} Disables digital sound effects (and would disable music, too, if this was already implemented :-) @{b}NoTitles@{ub} Do not show the title screens (Interplay&Parallax Logo) NOTE: Credit where credit's due This option was originally intended as debugging aid only, and should be removed in the final release. This option might go away in the final release of ADescent too. @{b}Piggy@{ub} Use an alternative PIG file. Not very useful if you don't have one... @{b}Shareware@{ub} Highly Experimental!!! Try to use the shareware .hog/.pig file. This is still untested, as we could not find a 1.4 or 1.5 shareware hog, if such a thing even exists. @{b}SMR@{ub} Open a screen mode requester for the in-game screen modes. This option is disabled if there are valid screen mode entries in the config file, otherwise it defaults to on. @{b}TexCache @{ub} Raises the internal cache size for mixed textures to . This normally defaults to 10, and may go up to 50. The use of this option is not so obvious. Internally, Descent generates temporary textures like the monitors on the walls by mixing a monitor and a wall :-) Those are stored in a cache for later retrieval. The TexCache option increases the size of this cache, making the game a bit faster. It is mainly used for the ViRGE version of ADescent, where this can make a dramatic speedup. @{b}VDirect @{ub} Only usable with CyberGraphX/Picasso96. Makes direct access to the video ram. Depending on your system, this might or might not be faster than offscreen rendering. Try it out and see for yourself. NOTE: Reports have it that this does not work with Picasso96. Should be fixed... @{b}Verbose@{ub} Intended for testing use. Makes ADescent a bit more talkative. When you send bug reports, it would be a good idea to redirect this output to a file and send it along with your report. @{b}Virge200@{ub} Only usable with the ViRGE version. Specifies that you actually have a 320x200 16bpp mode. If you only have 320x240, there might be problem with the ViRGE library's double buffering. To use this option, define a 320x200x16 screen mode with CGXMode. @{b}ip_target @{ub} Use the given host as default target for internet play. This name can be changed in the in-game internet menu. @{b}ip_port @{ub} Use the given port number for internet play. By default, port 2345 is used. Note that this option is only useful if 2345 is already in use by an other program, and that both players need to use the same port. Additionally, do not use port numbers below 1024, as these are reserved ports. As a rule of thumb, do not use this option, the default should work in 99.99999%. @{b}serialname @{ub} Overrides the default serial device name ("serial.device"). This is mainly useful for multiserial boards, or for using devices as the 8n1.device. @{b}serialunit @{ub} Overrides the default serial unit. Only usefule for multiserial boards. @endnode @node config "Configuration file" We have added a few custom items to the configuration file @{u}DESCENT.CFG@{uu}. This file is saved when you leave the game, unless you specify the @{b}NoConfig@{ub} option. Besides the standard entries, ADescent supports the following: @{b}Mode320x200@{ub} @{b}Mode320x400@{ub} @{b}Mode640x480@{ub} These store the (decimal) ModeID's of the appropriate screen modes. There should not be any need to edit them by hand, since they are set when you first start the game, and reset when you start using the @{b}SMR@{ub} option @{b}AHIAudioMode@{ub} Part of the Audio subsystem. This is the (hexadecimal) Audio ModeID to use. If left at zero, or not specified, it will use the default AudioMode from the AHI Prefs program. See @{"Hints'n'Tips" link hints} for configuration hints. @{b}AHIMixFreq@{ub} Part of the Audio subsystem. Specifies the Mixing frequency used by the AHI mode. No sanity check is made on this. If zero, uses the default frequency. See @{"Hints'n'Tips" link hints} for configuration hints. @{b}AHIMaxChannels@{ub} Part of the (you guessed it) Audio subsystem. Specifies how many channels the audio system should allocate. See @{"Hints'n'Tips" link hints} for configuration hints. @{b}AHIVolumeBoost@{ub} Part of the... Audio subsystem (!). Specifies a boost factor for the audio volume. Some people have reported that the volume was too low. 1 is the default setting. Setting this too high distorts the sound and causes ugly noises... See @{"Hints'n'Tips" link hints} for configuration hints. @{b}VirgeNumTextures@{ub} Only available/sensible in the ViRGE version. Specifies how many textures you want to allocate on the CV64/3D. The number depends on the Bus system you are using. See @{"the notes on the Virge version" link virge_overview} for a description of this. @endnode @node installation "Installation" Really simple, this one. Create a directory somewhere on your harddisk and copy everything there, including the HOG and PIG files. Now start the game by either entering "ADescent" from the shell (without the quotes - yes, you must say things like that) or double-click the icon. If there is no configuration file, the game will ask for screen modes for 320x200, 320x400 and 640x480. If you don't need or have one of those mode, choose anyone you want. After the main menu appears, select QUIT. Back in AmigaOS, load the configuration file into a text editor and edit the appropriate fields. For more info on that one, see @{"Hints'n'Tips" link hints}. @endnode @node virge "The ViRGE version" This part is only for the ViRGE version. Please read through all this before trying to run it, or you might have a really bad day... @{"Requirements " link virge_requirements} What you need for the ViRGE @{"Overview " link virge_overview } Features and stuff @{"Speed " link virge_speed } Speed's what matters, not size @{"ViRGE bugs " link virge_bugs } ViRGE-Specific bugs @{"In-game options " link virge_ingame } ViRGE in-game options @endnode @node virge_requirements "Special Requirements" @toc virge In addition to the stuff mentioned in the @{"normal requirements" link requirements} section, you will need the following: o A ViRGE chip. It would be a bonus if this chip is connected to a CyberVision64/3D, which in turn should be active in your Amiga :-) o CyberGraphX V3. Picasso96 will @{FG shine}not @{FG text} work with the current release, this might change later, but if it does, this day is still a while off... o cgx3dvirgin.library V2.10 must be installed on your system. It will be included in later releases, but currently you'll have to get it elsewhere (for example, the ViRGE page on www.vgr.com, in the V1.3 ViRGE demos). o 320x240, 320x400 and 640x480 15 bpp screen modes. Create them with CGXMode. @endnode @node virge_overview "Overview of Features" @toc virge @{FG shine}Features@{FG text} o Hardware-accelerated texture mapping in 15 bpp. o Hardware-Gouraud-Shading. o Everything looks @{b}much@{ub} better than the original 8 bit version o AND IT"S FASTER... :-) The new entry in the config file, @{b}VirgeNumTextures@{ub}, is used to tell the program how many textures to allocate on the graphics board. Currently this is limited to 64 on the Zorro II version of the CV64/3D, and 128 on the Zorro III version. You should, however, use only 60 and 124 respectively for safety. I should really build some detection code for this and adjust the value... Each texture map needs 8192 bytes of memory on the card. Each pixel has 16 bits, 1 bit alpha channel (transparency), and 5 bits of red, green and blue each. It would have been easy to add colored light if Descent supported it (there's some stuff in the source, but it is not used). By default, textures are filtered (Bilinear filtering, mode 4TPP, for the pro's). This can be toggled with ALT-F1 during the game... Go ahead and position your ship directly in front of a wall or grate, and press ALT-F1... Filtering is so fast that it can be left on, it does not make it notably slower (in 320x400/640x480, the difference is bigger). *UPDATE* ALT-F1 is now something different. See @{"In-Game Options" link virge_ingame} for a description. The Automapper is drawn with accelerated 3D-Line routines from the chip, resulting in a major speedup here. I also changed the layout a bit, hope you like it. No MIPMapping. The memory is a bit too low for this, especially on the ZII boards. Might show up later, but don't hold your breath. No perspective mapping yet, either. The virgin library does not support this directly, so I will have to use the Blit functions to program the Chip directly. I have already figured out how to do this, so the perspective mapping should be ready in the next release. Fogging is off-limits, sorry. Alpha Blending and Fogging does not work simultaneously on the ViRGE, but I need alpha blending for the transparency of grates and doors... Starting with release 0.5v there is an additional options menu for the ViRGE version. To get the menu, you can either select it from the Options menu in the main menu, or during the game with the combination ALT-F1. See @{"In-Game Options" link virge_ingame} for a description @endnode @node virge_speed "Speed of the ViRGE version" @toc virge I guess this is what all of you want to read... The speed is higher than on the normal version, although it might not be what you expected. It does an honest 15-20 FPS on my Z2-Blizzard 2060 machine. Sometimes it is faster (peaks at around 44 FPS when close to a wall), sometimes slower. The speedups of the main version will almost all have impact on the ViRGE version... - The ViRGE chip does @{i}not@{ui} accelerate 3D Calculations. This means that although texture mapping is faster, the underlying math is still as slow as ever. This means that to get the most out of this version, you still need a fast processor. - The game's 15 bpp now. More stuff has to be moved to the display for things that are not handled by the chip, like text, and explosions etc. Especially the bitmap scaler is quite slow, and will be replaced with assembler functions later. - I have not figured out everything the game draws, and some stuff might still go on in the background. Given some time, I will eventually remove this... Textures are cached on the card using and LRU (@{u}l@{uu}east @{u}r@{uu}ecently @{u}u@{uu}sed) strategy. This works reasonably well, and it currently gives hit rates of 98% and higher. For optimal performance, set the @{b}TexCache@{ub} option to 50. When the game exits, it prints cache hit statistics. @endnode @node virge_bugs "Bugs in the ViRGE version" @toc virge Most hangups can be cured by sending a break signal... Bugs currently known: - Textures distort. This is because the texture mapper is linear, but the U/V correction is perspective. Since the ViRGE version draws triangles and not scanlines, the problem is much more obvious in this version than in the normal version. This will be fixed with perspective correct mapping *UPDATE* Sadly, this will not be fixed. The problem is that the ViRGE's perspective texture mapping seems to have problem with wrapping textures. Since Descent uses them extensively, the only hope would be to subdivide polygons so that the texture no longer wrap. I might include something like this, but only after everything else is done. In the meantime, I'm going to adjust the clipper to interpolate linear u/v coordinates, so that the distortion will not be so severe. - Powerups, explosions and Headup-Display stuff might occasionally vanish.This is because I directly write into the ViRGE display buffer while the chip is still texture mapping (it can do this in parallel to the processor). This will vanish as soon as I have a fix for it, hopefully soon... @endnode @node virge_ingame "The ViRGE In-Game Menu" @toc virge The ViRGE version has an additional menu that can be either optain via the "ViRGE options..." entry in the options dialog (from the main menu), or in-game via the ALT-F1 combination. The Menu will look something like this (warning: ASCII-Art!): ViRGE Options... x Bilinear Filtering x Flashing Light Texture Mapper: o SubPixel mapper (req. FPU) o FullPixel mapper o SubPixel persp. (req. FPU) Other Options: FPS Limiter... @{b}Bilinear Filtering@{ub} Normally, when you fly close to a wall, you will only see a large cluster of pixels. With filtering, the ViRGE chip will "melt" those pixels so that they blend into each other. The result is a much smoother look. Since filtering normally has virtually no impact on speed, it is enabled by default. @{b}Flashing Light@{ub} Enabling this option causes the light in the mine to be colorized according to the color flashes used in the normal version. It's hard to explain really, so turn it on and see if you like it (I do...). This also shows how neat it would have been if the PC version of Descent supported the same colored light as the PlayStation version did... @{b}Texture Mapper@{ub} ADescent ViRGE now features two selectable texture mappers. The FullPixel mapper is what you know from previous releases. It rounds the coordinates to integers and then draws the polygons. With the SubPixel mapper, coordinates are @{b}not@{ub} rounded but rather passed directly to the triangle renderer. This results in a much smoother display and polygons don't seem to jump anymore. The SubPixel mapper now uses the direct-access feature of the cgx3dvirgin.library. The SubPixel mapper currently @{b}requires@{ub} an FPU, but this might change in future releases. The SubPixel Perpsective-corrected mapper is only experimential, since it does not work. You might turn it on for a glimpse what the game would look like with it, but you'll see it's shortcommings. Requires and FPU, too. I tried to implement the SubPixel mapper with fix point arithmetics, but there where problems with the accuracy, resulting in over- and underflows. This might be fixed in a later release. @{b}FPS Limiter@{ub} Brings up a menu where you can adjust the FPS limit. This menus looks something like this: x Limit FPS rate 5 Frames/sec. The toggle in the first line sets or resets the FPS rate limiter. If the red cross is visible, FPS limiting is on. You can adjust the FPS rate in the second line. Use Left/Right cursor keys to adjust the setting. A note about FPS limiting: The limit isn't accurate, especially with high framerates. You might set the FPS number to 25 and only get 21 FPS, even when close to a wall. To minimize overhead of this function (which is virtually nil when turned off), I traded accuracy for speed; we want to limit frame rate just when it would be too high. You might wonder why I included this switch. For o4o owners, it will most likely be useless, but for us 68o6o folks, the game sometimes gets too fast. This causes jerky movement and also causes dizziness. To avoid this, limit FPS rate to something like 25 FPS. Obviously, this function only ensures that the FPS rate will not climb @{FG shine}above@{FG text} this level. It will not ensure that it will be exactly this level. @{FG shine}@{b}@{u}A note about perspective-correction@{uu}@{ub}@{FG text} Sadly, it seems to be difficult to include this. The problem is that when the ViRGE draws with perspective-correction, it cannot wrap textures. But Descent makes use of this feature very often, e.g. for the floors in big rooms, so this means that there's currently no perspective correction. I have a perspective-correct mapper running, with the above limitations. It looks absolutely brilliant, no more warping and stuff, and frame rates are only a few ticks below the usual rates (about 2-3 FPS lower). Right after the start of the game I got around 12 FPS, not the usual 16 FPS. The only obvious solution would be to subdivide the polygons so that textures no longer wrap. While this is quite easy to implement, it means additional overhead, and I don't expect this to perform well. I'm currently investigating if there's any chance of making the texture wrap. @endnode @node bugs "Known bugs" There's probably quite a lot left. Here are the bugs we know of: - The @{b}-wbmode@{ub} switch doesn`t work on CyberGraphX. It`s not our fault, though, but CyberGraphX`. - Mouse and Keyboard used together result in jerky movements. - Sometimes the game hangs. This is because the object sorter sometimes keeps swapping two adjacent objects in an endless loop. Send a break to quit. Sorry 'bout this. Might be fixed soon. Should you discover more, please send them to us. See the section about @{"contacting" link author} us for addresses and email @endnode @node hints "Hints'n'Tips" @{FG shine}Debug Keys@{FG text} There are a few debuging keys active in the game. If you want to play in earnest, don't use them. Debugging Keys must be pressed together with DEL. a - Get all weapons c - The WIMP menu f - FPS counter toggle y - Explode the reactor L - Toggle headlights. And others... Play a bit... Pressing Right Shift zooms the view... @{FG shine}Audio@{FG text} There's currently no AudioMode requester in the game (I know we should add one). To get an AudioMode, use the @{FG fill}GetAudioID@{FG text} program from the AHI distribution to get an audio mode and mixing frequency. A word about the volume boost: AHI volume gets lower with each channel you add. So if the sound is too soft, you can either o Reduce the number of channels o Use AHIVolumeBoost The AHIVolumeBoost level should not be too high, you'll have to experiment. With 16 channels, you should use 2 or 3. @{FG shine}Joystick@{FG text} ADescent supports all analog joysticks and Flightsticks. Support for digital joystick will come soon. You can get cheap fligh sticks in almost all computer stores. For those living in Germany, I recently bought a Medion Erazer at ALDI for 30 german marks, and this stick works great. You'll need a special adaptor for Analog joysticks, see our web page for that. @{FG shine}Using other Descent ports@{FG text} As you probably know, there's another excellent Descent port on Aminet, by Christian Sauer. You might run into problems with this one if you use your pilot files, since it might not correctly write joystick configuration. So it's best to use a different pilot. Also, the keyboard layout is different. @{FG shine}Faster Loading@{FG text} For faster loading, increase buffers of the partition ADescent is on. For example, I always do an "AddBuffers Work2: 4000" before starting ADescent for the first time, and his @{i}dramatically@{ui} decreases loading times. @endnode @node history "History" 0.0 First release. First ever Descent port on Amiga!!! 0.1 AHI Support added 0.2 26-Feb-98 Mouse Support added. Preliminary AGA support. 0.3 Custom C2P added. Cleaned up CyberGraphX code to use WritePixelArray. CV64 should now display correctly. Added '-smr' switch Added '-nosongs' switch Added Analog Joystick support. '-numaxis' switch added, but still broken. Do not use 0.4 26-Mar-98 Added various stuff. including FPU, some speedups and bug fixes. First ever Amiga game to use the ViRGE chip on the CV64/3D... 0.5 30-Mar-98 Assmbler speedups, including texture mapper. "Not enought strings" message extended to warn about wrong version, to prevent further usenet postings ;-) Automapper now works correctly, alas no background ViRGE fixes. ViRGE automapper speed up. Various bug fixes. Minor additions. 0.6 05-Apr-98 ECS support Workbench mode Original keymap Speed -virge200 option added new ViRGE-specific options menu new sub-pixel interpolation mode 0.7 17-May-98 (What, really that long ?) Bugfixes (Automapper) Two player support Kali support (not really working right now) @endnode @node future "Future features" Those might be implemented/will be implemented in the future: o Networking is high on our list: TCP and serial/Modem o More speedups o Digital Joysticks and Pads ... @endnode @node author "Authors and Copyrights" This game was done by Parallax Software, and published by Interplay. This is the original copyright notice: @{b}THE COMPUTER CODE CONTAINED HEREIN IS THE SOLE PROPERTY OF PARALLAX SOFTWARE CORPORATION ("PARALLAX"). PARALLAX, IN DISTRIBUTING THE CODE TO END-USERS, AND SUBJECT TO ALL OF THE TERMS AND CONDITIONS HEREIN, GRANTS A ROYALTY-FREE, PERPETUAL LICENSE TO SUCH END-USERS FOR USE BY SUCH END-USERS IN USING, DISPLAYING, AND CREATING DERIVATIVE WORKS THEREOF, SO LONG AS SUCH USE, DISPLAY OR CREATION IS FOR NON-COMMERCIAL, ROYALTY OR REVENUE FREE PURPOSES. IN NO EVENT SHALL THE END-USER USE THE COMPUTER CODE CONTAINED HEREIN FOR REVENUE-BEARING PURPOSES. THE END-USER UNDERSTANDS AND AGREES TO THE TERMS HEREIN AND ACCEPTS THE SAME BY USE OF THIS FILE. COPYRIGHT 1993-1998 PARALLAX SOFTWARE CORPORATION. ALL RIGHTS RESERVED. @{ub} ADescent Amiga Port by Thomas Frieden Hans-Jörg Frieden C2P code by Peter McGavin, based on James McCoull's work IPX stuff by Philip Grossviler, based on AmIPX Joystick code by David Kinzer, with slight modifications ADescent uses the AHI Audio System by Martin Blom. ADescent_ViRGE uses the cgx3dvirgin.library by Frank Mariak. Many thanks to you, Frank, for the help with the virge stuff and for the library. ADescent uses CyberGraphX and Picasso96 in selected Cinemas. Many thanks to Mike and Matt at Parallax for releasing the source code and for funny comments in the source code... This port is freeware. We cannot be held responsible for any damage that arises from the use or abuse of this port. To contact us: Thomas Frieden Hans-Joerg Frieden tfrieden@uni-trier.de hfrieden@uni-trier.de Schloßstraße 176 54293 Trier Germany 0651/66410 Visit our web site at http://www.informatik.uni-trier.de/CIP/tfrieden/ Thank you, and good night. @endnode