A Jornada 720 version using the new GAPI

[Dan East]

[R0B]

I don't know how it could violate the lisence agreement, as long as we are turning the shareware version into a dll, and not the retail version.  I read through the license agreement and nowhere does it say that you could not use his software in a program, and, is a dll not a program.  An further more, if you did buy the retail version, although I am not positive if thelicense changes, nowhere does it say that you have to charge for your program, so you could give the dll away for free.  I would strongly not advise the second option, because that would simply hurt Larry, and posibly cause him not to update his project when gapi is updated.  What I was thinking was, create a dll that will only work with pocket quake.  Although, since pocket quake is open source, then people can freely look at the acess code, so that idea won't work.  Oh well, I guess it's time to create a "dll" and see if it works.  Actually, I have an idea.  First of all, you would need another file that quake calls, and then that file calls the dll.  This new file would not be open source, and when it is compiled, you would embed the file size of pocket quake or something inside of it.  If the size of the program accessing the new file is not the same as the PQ file size, then acces to the dll will not be possible.  So, here is a flow cahrt of my idea.<br><br>PQ->FileX->Compares File Size of PQ to Embedded siz<->Not equall then return<->equall then send code to dll for access<br><br>This way the code is sealed, and it would be very hard to make a program identical in size to PQ (although I am sure it can be done.  This would not violate the license at all, and will allow the use of the retail version of GAPI without modifying the code of PQ to much.<br>Last modification: Rob - 07/04/01 at 12:58:00

[Moose or Chuck]

Wow, how interesting. Too bad it's not new

[Digby]

Dan you don't need to dereference the function pointers in order to call the function.  The compiler will do this for you automatically.<br><br>

[R0B]

Just out of curiosity (I haven't looked yet), but does PQ call GXBeginDraw and GXEndDraw after every frame, or is it only a one time thing.  Because it is GXBeginDraw that creates the nag message, and that would make the game unplayable with the shareware version.

[Dan East]

Well, that's a grey area. According to the docs, it suggests "holding onto the buffer to draw mutliple frames" to increase performance, while letting go of the buffer if the app loses activation. That works fine on the iPaq. However on the Casio devices you have to call begin and end draw every frame. So I guess that is dependant on the OEM's hardware / drivers. I have no idea how Larry implemented this with his library.<br><br>Dan East

[R0B]

The way it appears to be implimented is that you only need to call it one time (At least I think).  I tested this with a program that changes the screen backgroung color rapidly and I only call GXBeginDraw one time at the beginning.  So, I believe that the 720 only requires one call.

[R0B]

I have a question about C programming.  Do you need to redefine funcions in every file, or is it enough just to have the header define them.  I'm asking this because I changed all of the GAPI functions back to their original names, and now when I compile it I get this.<br><br>Linking...<br>sys_win.obj : error LNK2019: unresolved external symbol GXGetDefaultKeys referenced in function WinMain<br>sys_win.obj : error LNK2019: unresolved external symbol GXOpenInput referenced in function WinMain<br>sys_win.obj : error LNK2019: unresolved external symbol GXGetDisplayProperties referenced in function WinMain<br>sys_win.obj : error LNK2019: unresolved external symbol GXOpenDisplay referenced in function WinMain<br>vid_ppc.obj : error LNK2019: unresolved external symbol GXBeginDraw referenced in function VID_GetScreenBuf<br>vid_ppc.obj : error LNK2019: unresolved external symbol GXEndDraw referenced in function VID_ReleaseScreenBuf<br>ARMRel/PocketQuake.exe : fatal error LNK1120: 6 unresolved externals<br><br>I do have gx.h included, so why is this happening?

[Moose or Chuck]

Do you have gx.lib imported into your workspace?

[R0B]

That's what I thought might have been wrong too, because I had that happen before, but the fix I used then isn't working now.  To import it, do you just go<br><br>1. Project/Settings...<br>2. Click the link tab<br>3. And type gx.lib in the object/library modules<br><br>Here is what that line looks like<br>gx.lib winsock.lib commctrl.lib coredll.lib<br><br>That is the only place that I have entered in gx.lib and I have included gx.h in vid_ppc.c and sys_win.c.  They are included like this.<br><br>#include "gx.h"<br><br>Am I forgetting something.  I don't think that the lib is corrupted or anything because the GAPI demo works just fine, along with a clear screen demo I made.  That is why I was wondering if there is anything else needed in C in order to make those functions work.<br>

[Moose or Chuck]

I usually just drag and drop it into the list of files in my workspace in VC++. It should show up there after that. But make sure when you type in gx.lib that it's in the same directory as all your other files or it won't be able to find it.

[Moose or Chuck]

And depending on where you put the gx.h file, it should be<br>#include <gx.h> //if it's in the default include dir<br>//or<br>#include "gx.h" //if it's in the same dir as all your other .cpp files

[Digby]

Larry Bank has a tech article that explains what GXBegin/EndDraw does and which platforms actually require their use in order to display the buffer contents properly.<br><br>If his library is truly displaying the dialog at every call to GXBeginDraw, then that's a poor design.  That would make the demo library pretty useless.  It would make more sense to display it when GXOpenDisplay is called.<br><br>

[R0B]

That's what I was thinking.  In fact, I wrote to the auther to ask him if he was willing to chang it to GXOpenDisplay, and he told me that he wouldn't.  I also asked him if you would consider changing the price, and he told me that 50 dollars was nothing for a development tool.  I still don't think that he understands that some systems require GXBeginDraw after every frame, and this makes his shareware library pretty pointless.  I was looking through the PQ source code, and I believe that GXBeginDraw is only called if the surface pointer doesn't exist.  I have not yet check to see how often that pointer is deleted though.  I am still trying to figure out how to fix my prevois problem, and any other sugestions will be welcome.  So far, there are about 20 more folders that now contain gx.h and gx.lib.  I'm putting it everywhere, just to see if that helps.  If I don't figure it out soon, then I am going to download the fresh source code again and start over, to make sure it isn't something that I did that caused it not to work.  So, any other help will be greatly appriciated.  By the way, I realize that many people have donated to this project, and I would like to point out that if a group of 720 users got together, or maybe just one, they could  purcase and donate the full version of gapi to this project.  This will only be needed however if PQ calls GXBeginDraw every frame, or something like that.<br><br>Is it just me or do I write too much in my posts?

[John Lomax]

I had the same errors as you when I tried to compile it...Everything seemed ok, but kept squirting those errors out that you get.<br><br>I tried a quick recompile of mame for the 720, got it to compile and run, and just after it initializes the screen it pops up with the gapi shareware message, so I know you can get it working in other things.<br><br>If we are fairly sure that it may be needed to call gxbegindraw every frame then I would be happy to donate towards the cost of the full version....maybe pocketmatrix could setup a donation site to raise the $50....We only need like a few of us really.<br><br>John