PocketQuake on monochrome iPAQ

[Thomas Wilburn]

Still nothing. I changed the GREYSCALE palette function to always return 255, which I figured was enough precision to create black pixels, but the screen still stays white. I'm calling it a night. If anyone wants to see the full vid_ppc.c source, send me an e-mail. Any help is appreciated, and thanks to everyone who has pitched in so far, especially Dan for his debugger instructions. Couple more days max and we should have this problem solved.<br><br>Otherwise I'm just going to wait until either it cools off tonight in my house or tomorrow night to finish debugging (I know how! Sort-of! &lt;grin&gt;). I'll keep you posted. <br><br>Hasta luego,<br><br>Thomas Wilburn<br>

[Chris Edwards]

no html here .... yet.. check back on wednesday

[Thomas Wilburn]

...one more thought before I sign off. Anyone know if the display on the 3100-series is rotated? Dan mentioned this before, but that could also be the reason I'm not seeing any display results from my code. I could be accidentally writing "above" the screen instead of to it. I'll try subtracting a column to get to the bottom later on. And will that affect my blit code? Hell if I know. Anyone?<br><br>Thomas Wilburn

[Dan East]

According to the GxDisplayProperties values you posted it is rotated.<br>The line:<br>[fixed]<br>*cdstGrey+=(char)(vid_curpal[*csrc+1] && 15); <br>[/fixed]<br>Should read:<br>[fixed]<br>*cdstGrey+=(char)(vid_curpal[*csrc+1] & 15); <br>[/fixed]<br><br>Dan East

[Digby]

Isn't 255 the value for full brightness?  <br><br>From what I've heard, each byte contains 2 pixels (4 bits each), and here's the kicker - the pixels are swapped within the byte!  That is, I think the upper bits in the byte actually represent the right-most pixel of the pair.  Maybe that's what kfDirectInverted means?  Or maybe that flag explains you using the value of 255 for black?<br><br>I don't have a mono iPaq to test this, but if the image looks whacked out try swapping the upper and lower nibble of the byte before writing it to the buffer.<br><br>

[TBone]

From my experience, greyscale systems work with higher numbers being darker. The reason I chose 255 as a constant for my function was that I'm working with bytes--8 digit binary numbers representing two 4-bit pixels. Whether or not the pixels are swapped (which I've heard, by the way, but figured was irrelevant and easy to fix once I had video), it doesn't matter, because 255 in binary is 11111111--or total black for both pixels. Swap them, it's still 255.<br><br>There are two possibilities why it didn't work, even after I made Dan's correction. The first is that I'm not writing to the correct chunk of memory. I could be throwing the pixels offscreen somewhere, or under the action buttons, and never even know it. For that matter, I haven't totally verified the area I'm writing to--it's going to take some time with the debugger to check all that. The second possibility is that my method for reading from/writing to the palette is faulty. Since it was originally constructed with shorts or longs and I'm reading chars out of it, I could be making one of those hellish logic errors that takes so long to find and correct with my math and throwing the calculations off. <br><br>Either way, I think I've gotten to a point now where (because it's no longer crashing once the game starts) I ought to be able to figure something out. It might be trial and error, or it might be some bit of info I'm missing, but I'm pretty confident I'll have it running within the week.

[Larry Bank]

You should have asked me <br><br>The mono iPAQ has "nonstandard video".  What that means is that the 2 pixels are packed with the left pixel being the LEAST significant nibble instead of the MSN as in most video displays.  Since this is backwards from the "GAPI standard", MS employs the same hack that is used on the EM500/E125.  It gives you a fake video buffer and then copies it to the real one on every GXEndDraw() Call.  So.... in conclusion... you can treat the video memory as left pixel = MSN, but you must do the following:<br><br>GXBeginDraw()<br><draw your frame updates><br>GXEndDraw()<br><br>I believe the default palette is 0="white", 15=black.  There are actually 16 dynamic palette registers in the memory directly before the video display, but it's best not to mess with them because it can hose things up royally if you write the wrong values in that area.<br><br>Have fun<br><br>Larry B.<br>

[DeFrAgGeD]

ooooooooohhhhhhhhhhh, Ouch talk about a b!tch<br>

[Digby]

Thanks for the clarification Larry.  <br><br>If what you're getting from GXBeginDraw is an address of a buffer in DRAM rather than actual video memory, does that mean that under the hood GAPI has to copy the contents from video memory to the DRAM buffer every time you call GXBeginDraw?   <br><br>Since most folks don't need to read from the buffer returned by GXBeginDraw, is there anyway you can avoid that internal copy from vidmem to DRAM?<br><br><br><br>

[TBone]

So in other words, I'm not seeing anything because I'm not calling gxEndDraw? Son of a bitch. All right, I'll undo my debugging/test code and give it another run tonight using that method.

[Dan East]

That explains why you have to call GXEndDraw every frame with the Casios. Can someone tell me why Microsoft can't spend .000000000001% of their billions of dollars to WRITE THAT IN THE FREAKIN DOCUMENTATION!?!?! I also wondered why it was so easy (similar) coding for all the different color displays "at the hardware level". I didn't think there would be such uniformity between all the various types of hardware. So really they are dissimilar, and some software hacks make it easier for us programmers at the cost of performance.<br>Unless some flag is set internally just to prevent you from doing it, it should work with a single call to GXBeginDraw at initialization, and only a call to GXEndDraw for each frame. That would be worth trying once you get it up and going, same with the MIPS version.<br><br>Dan East

[TBone]

I agree. Either give me direct access to the display, warts and all, or give me a hardware abstraction layer based on a single-consistent video buffer that is then copied over to video memory format. I think I'd prefer the latter, just to keep things easy to code, but I'd love a choice between the two, and I'd take most anything over the half-assed hardware access GAPI gives me on the 3150.

[Digby]

I always assumed you had to have a matching GXEndDraw for every GXBeginDraw call in your app.  I think I read that somewhere on Microsoft's website.  Or perhaps it's just my dealings with DirectDraw for the last 6 years.  <br><br>DDraw does this sort of thing quite frequently for managing texture maps.  The display drivers will typically store the texture data in a different format that the surface that the app sees.  This conversion process is referred to as "swizzling".  When you lock the surface to get a pointer to the memory chunk, a de-swizzling operation copies the data to a DRAM buffer.  When the app unlocks the buffer, the contents are swizzled to video memory.<br><br>The nice thing about DDraw though is that you can tell the API that you only want to write to the surface, hence it doesn't need to perform the de-swizzle.  No way to do that with GAPI I suppose.<br><br>Oh and let me tell you something else, don't plan on doing any GDI calls to a screen DC between GXBeginDraw/GXEndDraw.  They would obviously be clobbered by the internal copy from DRAM to VRAM by GXEndDraw.<br>

[Digby]

Found out something else that might be worth sharing here.<br><br>You can find out if you're getting a pointer to a DRAM buffer by calling GXIsDisplayDRAMBuffer.<br><br>You can minimize the number of bytes copied from the intermediate DRAM buffer to video memory by calling GXSetViewport.  I'm assuming that you'd want to call this before calling GXBeginDraw if you know you're only going to be updating a small portion of the screen.<br><br>

[Dan East]

Both those functions are undocumented, but are in the header file. Is that where you got them from? So if GXIsDisplayDRAMBuffer() returns FALSE then you need to call GXBeginDraw and GXEndDraw for each frame. Otherwise you can hang onto the buffer and reuse it.<br>I checked the gx.dll exports to see if there were any additional functions, but there weren't any beyond those listed in the header file.<br>Also, GXSetViewport wouldn't (couldn't) do anything unless GXIsDisplayDRAMBuffer() is FALSE. In that case it could increase performance, which would directly affect MIPS builds when playing PQ in portrait mode.<br><br>Dan East