Quake 3 Arena in your pocket

[CatPhone]

曾经梦想在火车里玩Quake 3 Arena ？当你坐在巴士的时候曾经对怎样得到Quad Damage表示怀疑？你想通过PocketPC和你的朋友一起游戏？不用惊讶，因为Quake 3 Arena CE版本已经在这里，Quake 3 Arena CE版本是为拥有PocketPC的人们特别设计。

系统需求：

- Pocket PC 2003 compatible handheld (ARM/XScale CPU)

- 120-150MB存储空间(通常是在一张256 MB SD卡上，可能适合安装在128MB SD卡上)

- 64MB可用的内存(128 MB将会工作得更好)

- 一份已安装在你PC的Quake 3 Arena，包括所有完整的升级补丁

你可以在官方网站www.noctemware.com下载，你也可以找到更多游戏规截图和游戏信息。

[PainQuaker]

没有PocketPC。

[HKMZ.com - Ah Son]

Installation

Ensure you have a copy of Quake 3 Arena installed on your PC. You're going to need the artwork/content from the game because it is not redistributable.

Run the pakconvert tool like this to build the pk3 file for your handheld: (replacing 'c:/q3a' path with wherever your Quake 3 Arena installation is. Also, note the usage of forward slashes in the path!)

cd pakconvert

bash ./pakconvert.sh c:/q3a

Copy everything over to your handheld. You will need a lot of space. 136MB of space on a 256 MB SD card is generally enough to store the game. (This is down from the 500 megs for the full pc version!)

We have stripped out the background music, and reconfigured the executable to require less memory. We have also shrunk the graphics and textures down to half of their original size since higher resolution really isn't necessary on a 240x320 (give or take) screen. We also re-encoded the FMV's in DIVX format so they'll fit better.

Specifically, you need these files:

q3ce.exe

gx.dll

libGLES_CM.dll

baseq3\q3config.cfg

baseq3\pak0.pk3

The other files are unused by the actual game.

Try playing it If you get like 4-6 frames per second, you're doing pretty well . You may need to adjust your amount of "program versus storage" memory in the memory settings control panel of your device. I recommend having at least 75MB free, but you can probably get away with less.

If you need to tweak down the amount of memory used by the game, open up the q3config.cfg, and reduce the numbers in the com_zoneMegs and com_hunkMegs fields.

Minimal setting are likely:

seta com_zoneMegs "12"

seta com_hunkMegs "20"

Though, I have gotten away with less memory in past, but not for too long

The game runs slowly due to the lack of any available hardware acceleration. However, hardward acceleration is currently being developed for various platforms.

Notes And Limitations

Network support is obviously limited. Your Pocket PC likely doesn't have a very fast internet connection, so your ping times are going to be crap. Hell, it might not even work.

The frame rate is about 6-8 FPS on my Siemens SX66 phone. That's a 400 MHz PXA263 doing completely software rendering. I wouldn't expect much better until we get some hardware acceleration in this thing. I might be able to pump it up by moving all the floating point stuff to fixed point. But I _do_ have a life. Then again...

It adds a whole new level of challenge when the bot you're fighting decides to hop onto the screen and cuts the frame rate down to about 4-5 FPS. He's likely hard to kill, because you can't aim for a damn.

But there's a silver lining. Sometimes the bot doesn't even load up, because the world 'AAS' files sometimes take a very long time to parse or something. If the bot doesn't load up, run around until you see an AAS message pop up on the screen and then manually add the bot through the menu. Something about the timing of the BSP code and the bot AI doesn't like something that runs as slow as your Pocket PC

The mouse does work. I wouldn't try to use it in-game though. The keypad is the way to go. Two hands, one for moving and jumping, one for shooting and looking up and down (remapped the volume control to do that), The various buttons around your device should bring up the console, the menu, and whatnot. If you have trouble with the default key bindings, edit the q3config.cfg file by hand and put better keys in.

I'd love to contribute to the 'Vincent' OGL-ES project, but it crashes every time I try using it with Q3CE, so it didn't make it into this build. Perhaps there is some room for collaboration here. It would be cool to have this port be 100% open.

You may have a hard time entering text, or a CD key or whatever, unless you have an external keyboard. Avoid menus where you have to type stuff in.

I had to eliminate support for the virtual machine in the codebase. This means that many 'mods' will not work for you, as the UI, Game, and CGame modules are all hard-coded into the program. If someone wants to find a way to get that working on the ARM cpu in a fast fashion (ha! and steal resources from our meager graphics?!) feel free to do so.

Compilation

Project files are supplied for eMbedded Visual C++ 4.0 (free for download from Microsoft) and Visual Studio 8. If you intend on using eMbedded Visual C++, I would recommend using the Intel Compiler for Windows CE plugin, as it produces much faster code than the default clarm.exe.

First extract the binary distribution zipfile. Lets call the top level directory 'q3ce' for now.

You will need to download the quake 3 source from idsoftware:

ftp://ftp.idsoftware.com/idstuff/quake3/s...eSource_132.exe

You will need to copy the quake 3 source tree over to the directory 'q3ce/quake3-1.32b'. Ensure that you merge the files in that are already in the quake3-1.32b directory.

You will need to get the Gerbera/Rasteroid library from Hybrid. Download Rasteroid from their website http://www.hybrid.fi, or find it on their ftp site. You want the OpenGL-ES 1.1 implementation for Pocket PC. I'm not going to provide a link to their download directly, because they want you to read their EULA thingy. Put the gerbera directory in 'q3ce/gerbera'.

You need to apply the patch. It's provided as a patch file. Apply the patch like this:

C:\q3ce> patch -p0 < q3ce.patch

This action will render that Q3A source tree uncompilable on platforms other than Windows CE, likely.

You should be ready to compile. Open the q3ce.sln or the q3ce.vcw depending on which compiler you want to use. Proceed to build the release version, or the debug version of the program. If all is well, you'll have an executable now. Proceed to build a working file set like the one in the binary distribution of q3ce if you don't want to use the one in the distro.

Design

Here's some of the design choices that had to go into making this port:

Screen resolution. You can't change it. The game will run at whatever resolution your LCD screen is natively. At some point I may implement something like "r_screenrotate" or whatnot, so you can play in landscape mode. Right now, you're lucky it works at all That said, a number of internal changes were necessary to get it to lay things out right in 240x320 or other 'long' or 'portrait' dimensions. It has only been tested on 240x320, but it will likely work on others. Please report any other screen sizes that work for you and send me screenshots!

Mouse. I added absolute positioning to the mouse code so that the UI could use the stylus to select menu items. In-game mouse code still uses relative mouse positioning, but i wouldn't really try to use it in the game very much.

Keys. I tried to get everything useful accessible. You'll note that the volume slider on many devices controls the up/down look. Everything does something. Click some buttons and find out, or edit your own q3config.cfg file.

Memory. Geez. Windows CE doesn't give you much to work with. The per-process space is only 32 MB because that's what the OS allots for. I replaced all the memory allocation functions with stuff that uses memory mapped files because they can be mapped in 'high memory' (almost sounds like DOS, doesn't it!). Also, configured the heap to allocate 24MB right at the beginning. This is primarily for Rasteroid/Gerbera, because the rest of the Q3CE code doesn't really use 'malloc()'. It uses the Z_Malloc and Hunk stuff which was moved the memory mapped files, as mentioned earlier.

Textures. I reduced the size of all the textures by half. This is effectively 'r_picmip 1', but permanent. There's no sense in having 256x256 textures on a 320x240 screen. Heck, we could probably get away with 64x64 in a lot of cases but i didn't need to push it. This saves on the size of the PK3 file.

The PK3 files. I removed the demos, and the background music. Left in the sounds though. The full motion videos are optional. This gets the PK3 down to 125-135 MB. It should all fit on an SD card now. Yes, it takes forever to copy to the card. For extra cool points, the full motion videos are encoded in DivX format and are much much smaller. Background music would be nice, but decoding an MP3 in the background while playing might steal our precious FPS.

OpenGL-ES. It's not OpenGL. But it's close. So I wrote a wrapper for it, and converted most of the Q3A code over that way. It's the way all the mobile 3D graphics are going. I would love to use a hardware implementation of OpenGLES, but there really aren't that many of them out there, and I don't have the devices for them. So software it was. Hybrid's stuff isn't open source, but it looked the best, so I went with it for this build. In the future a LGPL OpenGLES software renderer like Vincent would be cool too, but I couldn't get it to work in time for this release (crash bug in rasterizer).

Random bugs. Yes, I found a bunch of random bugs, overflows, etc in the Q3A source. And an ancient version of zlib that probably has that nasty security problem in it. I have a patch up to the newest zlib version here, but it's not applied to the Q3CE tree as distributed. I may opt to upgrade the zlib version at some point, if not only for the speed at which it operates.

Virtual Machine. The Q3A code uses a virtual machine to make modwriting and distribution easier. I eliminated that for speed purposes and built all of the modules statically. As a result, you can't use mods with this distribution. This was a real trick because the symbols all overlapped and whatnot. The patch gives new symbol prefixes to all the things that collided

Sound. The sound basically works. It's been brought down to 16 concurrent sound effects. If you don't have a fast CPU, it will compete with the graphics a bit. It may sound choppy. Depends on how much is going on. There may be a way to fix this a bit with buffering, but I haven't given it a whole lot of thought. I forward-ported the Quake 2 waveOut code to make this work, since Q3A really only had DirectSound support, and PPC2003 doesn't have DirectSound. For Windows CE 5.0, I may reimplement this.

__________________________

不太明白......

[CatPhone]

楼上的狠

[A.A.A]

已阅,帮顶!