PocketMatrix

As the designated porter for just about every open-source project that doesn't run on the monochrome iPAQs, I've been getting a little sick of waiting for source releases, and I don't have nearly as much time as I used to for this kind of thing. Therefore, I'm trying to use Daniel Jackson's Aero 2100 gx.dll source and create a GAPI implementation that will fool applications into running on greyscale. To do so, I'm allocating a color screen buffer and giving its address to apps, then running a very fast conversion (4 bytes at a time) on it at GXEndDraw(). What I need is information to make sure that I'm accurately duplicating the 3600 series video setup. To that end, I'd really appreciate it if someone could post the results they get when they run the GAPI Properties applet from PocketSNES.com (found in the download section). If I get this working, and it shouldn't be hard, it will mean that anything running on a color ARM machine will run on a black and white machine, finally giving these machines the leg up they need to truly compete with color.

And I'll be able to play RocketElite. <grin>

Thanks in advance,

Thomas

A problem that I can see with your idea is that there are some existing games that never call GXEndDraw. The call GXBeginDraw once at the start of their game and then cache the frame pointer address.

They might heed the value returned from your implementation of GXIsDisplayDRAMBuffer. If you return TRUE (which you should be) they might not cache the pointer.

Also, I don't think anyone is making gray scale devices anymore. Thus your audience is fixed and will only get smaller over time. All new Pocket PC devices must be ARM-based and have 16-bpp color screens. Still, I think it's cool you're doing this and it shouldn't be a lot of work to prove your concept. Good luck.

First, many programs do not indeed call gxEndDraw, but many of the most popular ones do, especially those that are cross-platform. It doesn't hurt to try.

Second, I will likely implement the GXIsDisplayDRAMBuffer() modification, but I think it's far more likely that programs do not call this as opposed to GXEndDraw.

Finally, I assume you're new to the forums. If you weren't, you'd know that I've done several ports due to the suprising demand that exists. Because they're cheap and have fantastic battery life, the greyscale devices are often popular among a certain class of people, as well as being used in many Stinger devices. The community on Brighthand is nigh-fanatical, and even if they weren't, I'd want something like this myself. As someone once said, 99% of programs are written to satisfy a programmer's personal itch. The inability to run many games just because no-one will take the extra time to code for them is my personal pet peeve.

Okay, I think I really need that information, so I'd appreciate someone posting it. Right now, two crashes are happening. I'm using PQ as a test app because it does call EndDraw and its implementation is the one I'm most familiar with. It's dropping out either at address 0006c3a4 when I feed it my buffer's pointer (adjusted forward by 2*320 to fake the iPAQ's landscape orientation), or later on when I try to copy my video buffer to the standard greyscale screen. The latter is probably just a mistake in my loop, and I won't have a problem fixing it later, but I'm a little upset that just writing to my malloc'ed 320*240*4 (just to be safe, I know it's supposed to be 320*240*2) buffer is causing some sort of invalid error. I'm not sure if it's an alignment problem or not. Anyone have any ideas?

Oh, and in case it helps, PQ does run perfectly (albeit with no video, but sound) when I pass NULL as the video pointer from GXBeginDraw.

< forgot to login before - I'm "Anonymous">

Well I'm not too new here, but I have no idea of what work you've done. Probably because I don't play that many games these days and I don't recall seeing your name here in the dev forums.

Anyone who is writing a game that doesn't heed the return value from GXIsDisplayDRAMBuffer is blind when it comes to graphics performance.

I do salute your enthusiam and I'm sure that the people who have gray scale devices are elated that someone is thinking about them. If this makes you and your Brighthand friends happy and you enjoy coding it, I say go ahead and do it. I was just saying that the market is stagnant and will only decrease going forward. It would be similar to developing a game for the Dreamcast right now.

use the [ code ] and [ /code ] tags next time, TBone. It makes your code and posts easier to read.

It appears TBone released a beta of this yesterday:

http://mason.gmu.edu/~twilbur1/downloads/gx.zip

Dan East