PocketQuake on monochrome iPAQ

[Thomas Wilburn]

As soon as I get my CF card in the mail so I have the room, I'm planning on porting PocketQuake to 4-bit color so that I and other cheap bastards with iPaq 3150s can play Quake with the rest of you. I've been running through the source, and I have two problems that I hope someone can help me with. First of all, I tried a build and eVC complained vocally about two missing includes (in addition to the GAPI, which I'm grabbing now): unix.h and alloc.h. The compiler also does not properly find the resources listed in winquake.rc. If anyone knows how I can alter the project to remove these errors, I'd appreciate it. <br><br>Additionally, I think I can handle updating vid_update() myself (congratulations on some beautifully portable code there. I love it already), but I'm not too familiar with the vid_palette() section since most of my dev work has been on PalmOS. BitBank sent me a quick function for converting rgb to 4bpp greys ((r+2G+B)/4). Can I just plug this in, or is something more detailed involved?<br><br>Thanks for your help in advance,<br><br>Thomas Wilburn

[Dan East]

I've not done any 4bpp programming lately, but that doesn't look familiar. Check the docs for the GXDisplayProperties struct. It has an algorithm for accessing pixels in that format.<br><br>Dan East

[DeFrAgGeD]

Teah i know the way you are saying ((R+2G+B)/4) That is the older way they used to do when the other grayscale devices where hip. Now like Dan said there should be an algorithym for access that makes it easier.

[Thomas Wilburn]

We'll have to see. I've got the project compiling with no errors for iPAQ release, but I still don't have the memory card so I can't test it out. What a pain.<br><br>Right now I'm sticking with BitBank's algorithm because I'm only using it for the vid_setpalette(), making it a one-time operation (I think). There I'm not too worried about speed. I also can't find the gx version of the conversion, so I'm not sweating it.<br><br>Just to keep people up on what I've done so far: I'm assuming that the color on the iPaq is in 8-bit chunks and not true 4-bit like on the Palm (where each byte actually encodes two pixels). To make this change, I added a new palette generator (using the above function) when the device's g_displayProps.cBPP is equal to 8. That's not amazingly portable, but since the 3150 is the only 8-or-less-bit display device still really around, I think it's probably pretty safe. <br><br>After altering the palette, I set up the same kind of test for copying to direct display memory. If the device's bits/pixel is 8, I'm copying the off-screen buffer by char instead of by short. I think that's probably fairly safe.<br><br>Looking further back on it, though, and after running the GAPI Properties applet from pocketsnes.com, I think it's going to take more work than that. That little program returns the BPP as 4, which means that I may have to copy pixels two at a time, combining them into a single byte when I finally blit them to the screen in vid_update(). That'll be a minor pain, to say the least. Does anyone know if this is the case, or if I've made any other mistakes with this approach? This is the first time I've had to work with anyone else's code, and I have to admit that at times I'm a little bit overwhelmed.

[Thomas Wilburn]

More updates:<br><br>I still don't have the CF card (should tomorrow, then we make with the testing) but I did spend some time today familiarizing myself with Jacco Bikker's EasyCE source, which includes a section on the joys of iPAQ 3150 low-level graphics. It looks like the little bastard is true 4-bit color, so I am going to have to pack the bytes for this format. That's not a huge deal, and in fact I think I can just use the basic ideas from Bikker's routines to perform the conversion and copy the pixels two at a time. The display orientation seems to be the same, so that shouldn't be a problem either. With this info, I should have it up and running within a week or two.

[Thomas Wilburn]

Update: the monochrome iPAQ is giving me fits, especially when it comes to accessing video memory. All attempts to write to the pixel found by GXBeginDraw_() crash the device immediately. Doesn't matter what I write, doesn't matter what type I use for the int*, doesn't matter how much I add to the pixel as "padding." <br><br>So I'm fed up with attempting to adapt the vanilla PQ routines. Instead, I'm going to try to copy Jacco Bikker's EasyCE routines over as intact as possible. Since I know they work (or at least I assume he's tested them) this should be pretty much a foolproof last-ditch effort. If it doesn't work, well, I'm at a loss. I've tried everything I could think of, and none of it's been working so far. We'll see.<br><br>I'm not sure if this will be faster or slower than the routines used for the color version. On the one hand, EasyCE calls for me to get a new pointer to the display surface every time I go through the display loop (and I'm not messing with it until I understand it more or at least get it working). On the other hand, I'll be copying single bytes from one place to another instead of 2bytes per pixel. On the gripping hand, the current code will probably convert from the rgb565 palette to Greyscale from within the loop, which isn't expensive but still adds cpu cycles. If this works, I'll try and move as much as possible out of the display loop and see if that helps. I think it'll be playable in any case, for two reasons: first, the screen is a cheap passive-matrix, which I've found make low framerates tolerable due to their "blur" effect. It's kind of like fullscreen anti-aliasing for free. <grin> Secondly, the real meat of the rendering cycle seems to be in the polygon rendering. No matter how expensive I make it, I have trouble believing that any buffer-copy routine is going to be much of a bottleneck. Here's hoping. New update tonight if it works.<br><br>Thomas Wilburn<br>viva la 3150!

[Dan East]

Have you tried debugging on your device? What is the value of pScreenBuf and pDrawStart immediately before you begin blitting?<br><br>Dan East

[Thomas Wilburn]

Ah, debugging. Man, that would be great if I knew how, but this is really my first time working with Pocket PC and/or Visual Studio and so I don't. Is that in the eVC help file, or can you help me get the debugger running?

[Thomas Wilburn]

Never mind, just had a look through the help to see what's involved. Compile for debug, start it from the desktop, gotta have breakpoints to examine variables. Looks pretty simple. When I get home I'll try it and report what happens.

[Dan East]

Select the Win32 (WCE ARM) Debug configuration, then build like normal. You can set breakpoints on specific lines by clicking on the Hand toolbar icon (or by pressing F9). Once you've set your breakpoints then hit F5 to begin debugging. Now, if you are using USB it will be very slow and take a minute or two to get going. If you are using plain serial it will be even worse. Ethernet is the best, but most people don't have CF ethernet cards laying around (only takes a second or two to start up a debug session).<br>The execution should stop at the line you set the breakpoint at. You can then check the values of variables by using the Watch Windows, or by hovering your mouse pointer over the variable in question for a few seconds. You can hit F10 to step to the next line in the code, etc. It will take several seconds (up to a minute) to step from line to line if you are not using Ethernet.<br><br>Dan East

[Digby]

[Dan East]

[Digby]

[Thomas Wilburn]

Yeah, looking back on it, the debugging comment is pretty funny, isn't it.<br><br>Okay, here's some good info. Keep in mind that it takes me forever to get this stuff because my laptop is slow, and because I have to keep my stylus managing the memory until Quake launches with my pitiful 16megs ram.<br><br>First, the GAPI props struct {<br>     cxWidth = 240;<br>     cxHeight = 320;<br>     cbxPitch = 160;<br>     cbyPitch = 0;<br>     cBPP = 4;<br>     ffFormat = 1064;<br>}<br><br>That 0 for cbyPitch is wrong because there are 2 pixels/byte. It's a rounding error, ignore it.<br><br>Also, the address of the screen seems to consistently be 0xAC01209F. At least, that's what pScreenGrey (my replacement for pScreenBuf) reports. <br><br>Here's the explanation for the first problem I've been having: whenever two calls are made to gxBeginDraw(), the second pointer is left null (==0x0). That explains why my attempts to add a char* in addition to the short* pScreenBuf didn't work. After switching the order, now pScreenGrey is the memory address and pScreenBuff is NULL. Ouch. This will have to be a IFDEF compile for source compatibility, looks like.<br><br>So far so good. Stepping through the code...<br><br>Fixing a couple of logic bugs...<br><br>Okay. So far, I haven't had any crashes looping through, now that I've actually got a screen address. I'm going to recompile for release and try to run it, see what happens. Here we go...<br><br>Here's the code I'm using right now:<br><br>if (g_dispProps.cBPP == 4) {//check to see if this is the mono iPAQ<br>                  cdstGrey=pDrawStartGrey;//pDrawStartGrey replaces pDrawStart, it's a char*. ditto cdstGrey for cdst.<br>                  csrc=vid.buffer;<br>                  nextRow2=nextRowGrey;//same thing as pDrawStartGrey: new version to figure the rows correctly in 4bpp<br>                        while (csrc<colEnd) {<br>                              rowEnd2=csrc+rowEnd;<br>                              while (csrc<rowEnd2) {//the next two lines actually set two pixels in 1 byte.<br>                                    *cdstGrey=(char)(vid_curpal[*csrc] << 4);<br>                                    *cdstGrey+=(char)(vid_curpal[*csrc+1] && 15);<br>                                    cdstGrey++;<br>                                    csrc+=2;<br>                              }<br>                              cdstGrey+=nextRow2;<br>                              csrc+=nextSrcRow2;<br>                        }<br>            } else {      <br>                  cdst=pDrawStart;<br>                  csrc=vid.buffer;<br>                  while (csrc<colEnd) {<br>                        //Calculate the ending row pixel<br>                        rowEnd2=csrc+rowEnd;<br>                        while (csrc<rowEnd2) {<br>                              //The next line is what actually sets the color value of the display pixel<br>                              *cdst=(short)vid_curpal[*csrc];<br>                              //Increment our source and display buffer pointers one pixel to the right<br>                              cdst+=xPitch2;<br>                              csrc++;<br>                        }<br>                        //Move down to the next row and all the way to the left<br>                        cdst+=nextRow2;<br>                        csrc+=nextSrcRow2;<br>                  }<br>            }

[Thomas Wilburn]

Step in the right direction: I have sound. No graphics, but it makes it far enough to give me sound, and I can blindly step through the menus to start a single-player game. That's very good--better than I was doing. I'm pleased. I'm guessing that the problem now with my lack of video has to do with my palette generation. Right now, the function looks like this: <br><br>unsigned short GREYSCALE(unsigned char r, unsigned char g, unsigned char b) {<br>     //Thomas: 4-bit greyscale.<br>      return ((r + 2*g + b)/4);<br>}<br><br>Anyone have any clues? Or could it be a problem with the blitting code I wrote earlier? I'm going to set the palette function to return black for all colors temporarily and see if that changes anything--if it does, we'll know that my conversion and not my copy code is faulty.