PocketQuake Fixed Point Modifications

by **Phantom** » Feb 21, 2001 @ 8:14am

People, I have talked a bit with Dan about this fixed point stuff. Let me introduce myself: My name is Jacco Bikker, I am 27 years old, and I have been working with 3D graphics since I was 12. I wrote about 6 3D engines, of wich 5 where software-only, and 2 where for my boss.

Right now, I'm working on some voxel graphics on the iPaq. Before everyone gets too excited: I can spend some time on PocketQuake, but I have no idea how much, since I have *lots* of other projects, not to mention my job (currently, PS2 developer) and family. I intend to do some quick fixes to gain a couple of frames, just to get the other coders going. I think this HAS to be a joint effort. On the technical side of things: Quake is using A LOT of floating point calculus. To get this 'fixed'

I suggest we don't try some kind of a generic solution (Dan already tried that) but instead focus on the end of the pipeline, i.e., the actual polygon rasterization. There are two reasons for this: 1. This is probably where PocketQuake spends most of it's time (Dan, can you confirm this? How much slower does Quake run at full-screen landscape mode?) 2. There is no code that relies on the result of these calculations. Wich means that errors are not propagated to other parts of the engine, causing unexplainable errors. After that, we can work our way up: First, modify the code that supplies the polygon rasterizers with data, and so on. Some other ideas that might gain a couple of frames: - The texture cache is also a loose end. It is used to store mixed texture/lightmap combo's; if we loose precision there, this will show up on the screen, but it won't cause havoc elsewhere. - The size of the texture cache is currently 600Kb. We might want to increase this amount; mixing is expensive. I think we can double the frame rate by making the polygon code fixed point. That's a small amount of code; this should be quite possible. By tweaking the texture cache we should be able to gain another 2 fps or so, making Quake VERY playable on the iPaq. I'll start tonight. Who wants to join? How is this SourceForge stuff doing? Who is who?

If you need to talk to me, please try ICQ. I'm online all day (but I live in Europe). Greets Jacco.

by **Dan East** » Feb 21, 2001 @ 9:17am

240x180: 3.97 fps 320x240: 2.74 fps The ratio of pixels between the two modes is 1.78. The ratio of fps is 1.45, which shows a very strong correlation between the number of pixels rendered and the fps. In case anyone wonders how I am getting these fps values, I do a soft reset of the device, and start Quake with a new single player game. Once the starting room opens I don't move the character at all. I then execute the console command TIMEREFRESH. Because the surroundings are exactly the same each time this provides a relatively accurate method of generating a base framerate. Dan East

by **Phantom** » Feb 21, 2001 @ 9:21am

Dan, How are you displaying the buffer on the iPaq? Do you rotate the buffer into place? I mean, this could give landscape mode a slight advantage, because this rotation wouldn't be neccessary. - Jacco.

by **Dan East** » Feb 21, 2001 @ 9:35am

In vid_ppc.c::VID_Update() I blit Quake's palette-based bitmap to the video buffer pixel by pixel, looking up each pixel in the palette. There would be no performance difference between landscape and portrait, except for the fact that 1.78 times as many pixels must be copied in landscape. Technically the iPaq's video buffer is landscape, but since each pixel must be looked up in the palette, and blitted individually, this makes no difference. The rotation is performed during the blitting process no performance loss results. I convert palette entries to the iPaq's RGB 565 scheme when the palette is set, so blitting involves copying the palette value (a short) directly to the video buffer. Dan East

by **Phantom** » Feb 21, 2001 @ 9:41am

OK, thanks for the info. I'll try to replace the span rasterizers with some affine rasterizing code tonight, to see what the theoretical achievable gain is in that part of the code. Should be quite a bit, based on your data.

by **Phantom** » Feb 21, 2001 @ 11:27am

Dan, I have been looking around a bit: In source d_edge.c there is some code that calls the span rasterizers in d_scan.c. Each polygon is stored as a linked list of spans, each span is on a single scanline (originally I thought these where the 8 or 16 pixel perspective corrected subspans). The span rasterizers come in a couple of flavours: One for the sky, one for actors, one for scenery and one for 'turbulence' (for submerged scenery). Apparently, actors are always drawn without turbulence, even under water. Is this true? The scenery rasterizer is perspective correct, I will remove this functionality for the moment, because those calculations are very expensive and the result probably hard to notice on such a small display. These span rasterizers take only a single structure (espan_t) and use quite a lot of floating point code internally. Interesting enough, the espan_t structure contains u/v coordinates in fixed point.

The span rasterizers are about 50 lines of code each, so this is going to be an easy start. I'll let you know if the conversion is easy, and if it pays of.

It should, by the way. A lot.

The code that constructs the span lists is not too hard either, so it should be relatively easy to have fixed point polies soon. There is some very nasty code further up the pipeline though; that's gonna be a rough task. - Jacco.

by **Moose or Chuck** » Feb 21, 2001 @ 4:12pm

I'm glad to know that someone professional cares about us and is working on the project =). Keep us informed, but work on PQ more often than informing.

by **Dr. Phat** » Feb 22, 2001 @ 2:18pm

Thats Right! Professionals rule.

by **Matt Keys** » Feb 22, 2001 @ 3:23pm

You know, you guys elude to the idea that Dan is not a "professional." Keep in mind, before Dan came along Quake was thought to be impossible to port.

by **999** » Feb 22, 2001 @ 3:33pm

Thanks for pointing that out Matt. When I read Moose's original post it didn't really sit well, but I thought it was in how I read it. Now, let me just clarify a little something: Dan is the [/b]Man[/b]!!! 'nuff said.

by **Moose or Chuck** » Feb 22, 2001 @ 5:53pm

Ya, I didn't mean any disrespect to Dan East. He started this, he's already a legend. But Jacco comes along with his experience and tells us ways to easily optimize the game. Jacco is the person that, I believe, will make it possible to play on Casio's, and even better for Ipaqs. Since i own a Casio, Jacco's plans mean the difference to me.

by **Chris Edwards** » Feb 22, 2001 @ 9:12pm

by **Phantom** » Feb 23, 2001 @ 4:28am

by **Phantom** » Feb 23, 2001 @ 4:31am

by **Dr. Phat** » Feb 23, 2001 @ 10:19am

As Mr. Moose said, it has already been established that Danis the man. Therefore, we were just ushering Jacco into a relatively similar position. We meant no harm to Dan's rep. That is all-