by Dan East » Feb 16, 2001 @ 12:20pm
2/16/2001<br><br>Ok. Here are some notes regarding the Pocket Quake source code.<br>First of all, it only contains the source code that Pocket Quake uses. So source files specific to other operating systems (Linux, etc) are not included. I'm just trying to keep things straightforward. Also included are the sources for the gzip compression routines.<br>This, of course, is to be built with Microsoft's eMbedded Visual C++. For those of you who don't already know, it's free from Microsoft. Yeah, it's hard to believe MS is giving something away.<br><br>The two primary files containing the Pocket PC specific code are sys_win.c and vid_ppc.c:<br><br>sys_win.c:<br>Contains the OS-specifc IO routines. This is the primary area where the gzip additions are.<br>Contains the WinMain application entry function.<br>Initializes the Game API within WinMain. I decided to dynamically load the gx.dll, in order to provide the user with concise error messages if the dll could not be found (Pocket PC's error messages if a statically linked DLL can't be found really suck, it's like "Your application won't run, we know why, but we won't tell" ).<br><br>vid_ppc.c:<br>Contains the Quake video routines (setting the available modes, etc)<br>Converts and stores the palettes as set by Quake into the rgb scheme of the device (565 in the case of the iPaq).<br>Blits Quake's palette based bitmap to the device's display buffer.<br>Handles key mappings.<br>Contain the MainWndProc.<br>Handles all key and mouse events.<br>Draws / handles the Video Menu in Quake<br><br>Those of you who desire to port to other Pocket PC devices should only need to modify the VID_Update and VID_SetPalette functions in the vid_ppc.c file.<br><br>The file cl_demo contained stdio routines that directly accessed the wad file (I don't know why ID Software did not use the OS-Specific routines in sys_win, as it does elsewhere). These routines had to be modified to support gzip.<br><br>The sound routines required very little tweaking for Pocket PC. Basically I had to remove all of the DirectX sound support, and make some mods to allow for sound mixing further ahead in time. <br><br>Sound is currently mixed 200ms ahead, where in Quake it is normally 100ms ahead. This causes slightly noticeable (although not bad) lag delay in the sound.<br><br>The network routines were also easily modified. Quake was dynamically loading wsock32.dll, which of course differs for CE. So I simply modified the routines from pointer functions to direct calls and built statically linking to the winsock.dll.<br><br>ID Software really did a good job writing portable code. It took me around 50 hours for the initial port of Quake (I downloaded the source from ID on Jan 15th, started porting the next day on Tues, announced my success on Friday, and released it on Sat. the 20th. You can see why I didn't want to release the source after only have been working on it for 4 days). The addition of the onscreen controls and CF support took around 10 hours, and the sound and network support together took around 4 hours.<br><br>ID Software must build with a low warning level. The compilation of Quake generated thousands of warnings (which I can't stand). These were primarily fixed to int or int to fixed conversion warnings, double to float, and signed / unsigned mismatch. I corrected these warnings by providing appropriate casting. I did not document these changes as they were so numerous. Pocket Quake will now build for either Arm-PocketPC or x86 Pocket PC Emulator without a single warning.<br><br>Now, regarding the fixed point conversion. I attempted a global replacement from float types and operators to custom fixed point types and operators. This was done by identifying the global variables and structure definitions, making a duplicate of them (appending FPM to the name), and modifying them so that float types (or references to other structs containing floats) are now fixed point type. Next I went to the implementation, and made a duplicate of any function accessing the old float types or structs (appending FPM to the name of the new function), and modified them to use custom operators in place of the C operators. Further, any function referencing a float-containing function was changed to call the new FPM function. So operations such as a floating point Dot Product:<br><br>float DotProduct(float *vec1, float *vec2) {<br> return vec1[0]*vec2[0]+vec1[1]*vec2[1]+vec1[2]*vec2[2];<br>}<br><br>would be converted to:<br><br>fixedpoint_t DotProductFPM(fixedpoint_t *vec1, fixedpoint_t *vec2) {<br> return FPM_ADD3(FPM_MUL(vec1[0],vec2[0]),FPM_MUL(vec1[1],vec2[1]),FPM_MUL(vec1[2],vec2[2]));<br>}<br><br>At first I had hoped to just use macros for the fixed point implementation, but I realized that would not be possible. Plus, I wanted to add in range / precision checks for debugging. So, implementation of the fixed point math is in FixedPoint.c. These routines need further optimization; at the initial stage I was more concerned with accuracy than performance.<br>After converting all functions / globals / structs to fixed point I began testing. I added in overflow / underflow / precision checks into the fixed point implementation and fired it up. This is where I realized the range / precision problems. I started converting the trouble areas to 32.32 (the product of two 16.16 vals is 32.32) using Microsoft's __int64 type. Before I got too far in that area I did a benchmark comparing 64 bit integer operations to floating point. Well, float operations are faster than 64 bit int, so there would obviously be no use in continuing if the result will be slower than the original. However, using assembly it is possible to work around this problem (faster 64 bit integer operations). This is where someone else is going to continue on with the fixed point conversion (I don't want to reveal his name until I check with him). He has fixed point 3d programming experience with Windows CE.<br><br>A further note. Any replacement type for float must be the same size as float (4 bytes). There were some structs I identified whose size could not be changed (don't remember them in particular, I just remembered coming across them). Of course various calculations involving compound operations can be performed in 64 bit and then converted back to 32 for storage.<br><br>The FPM functions and globals are all in place in the source I am releasing. They aren't built unless USEFPM is defined quakedef.h. If USEFPM is defined then the new FPM routines are built in place of the original code.<br><br>I certainly plan on continuing with the project. I just can't dedicate the time required for huge, low-level modifications like continuing with the fixed point conversion.<br><br>I would like to see at least some level of coordination between developers that are interested in contributing to this project. If you are going to create a MIPS port, work on fixed point, etc, please post to the Pocket Quake forum so others won't duplicate your work. Also, I would like the official website to host all the various ports of Quake, just to keep things simple for the consumers. Chris Edwards is in the process of setting up the site for that purpose.<br><br>Dan East<br>pocketquake@pocketmatrix.com<br>www.pocketmatrix.com/pocketquake<br>Last modification: Dan East - 02/16/01 at 09:20:17
Source
