PocketFrog Bug - Dell Axim

[Bapdude]

[Kzinti]

[Conan]

[Presto]

[Bapdude]

Please don't think that I am "complaining" about PocketFrog. Believe me, I am *extremely* grateful for PocketFrog as it has saved me so much time and headaches that I WAS having before I started using it. PocketFrog gave me the tools to do more than I could ever do on my own.

I've been coding for the PalmOS for the past 3 years, so I'm certainly not an expert in the Windows arena. My first port to the Pocket PC is almost finished (thanks largely to PocketFrog), and this application error is the only remaining problem that I have left to fix.

I would gladly do my part to help debug this problem, but coming from Palm OS development, I'm not very savy with the debugger. How do I debug a program on an actual device? I've been developing in Visual C++ on my computer and then downloading to my Axim for the final testing. If someone can give me some quick instructions on how to get debug info on this error, I will gladly post my results.

Thanks guys!

[Conan]

If you want to try a device debug yourself make sure that you have the latest active sync & within evC3++ do a build of a debug version after setting all it's project settings & tools options setting so as to pick up the correct PF lib, PHAL lib & pointing to the correct includes & library folders just like your release one.

When you do a build & it downloads the debug version to the device you can then do a build / start debug / go & the app will start on the device.

However: when you power off the device activesync stops working so I cannot tell what the debugger was doing. Then evc++ crashed & exited.
I can try the Entrek debugging tools demo:- When the app crashes on power off the Entrek tool stops giving data.

So I think it's a new question: What actions must a developer take other than suspending Hekkus when a suspend happens? Should the game's main loop check every time & do nothing if suspended or what?

[fzammetti]

Thierry, was PF *ever* coded to handle these types of situations? I only ask because I didn't add any functionality in this regard to the later versions, so if it wasn't there to begin with, there's the problem.

[Bapdude]

[fast_rx]

[Kzinti]

[Conan]

[Bapdude]

[adde]

Ok, not saying I'm holding all the answers (heck, I don't even own a PDA) but here's my guess:

The "Exception: 0xc000005" is an "Access Violation" which happens if you try to read/write from/to a NULL pointer or a dangling pointer (i.e. a pointer to a piece of memory that is not valid).

Conan wrote: "does this mean that in PocketFrog everywhere displaydevice is used I need to add in functionality to test if it's valid before doing anything with the screen?"

No, because if you managed to start your game using Game::Run() (which in turn calls Game::Init() followed by Game::GameInit() and then continuesly calls Game::GameLoop()) then it has already created the DisplayDevice for you and verified that it is not null. If it was, then Game::Init() would have returned false and Game::Run() would have exited with an error and not ever call Game::GameInit() or Game::GameLoop().

This is good news because it meens that you don't need to worry about the DisplayDriver (unlike what fast_rx suggested earlier).

But the bad news is (and this is once again traced back to the file pocketpc.cpp) is that the global pointer pointing to the DisplayDriver is never freed on a shutdown or exit. Normally this is not a problem since when a program exits all its memory are returned to the OS (but don't bet on it). I don't know exactly what happens on a Dell Axim when the power button is pressed so from this point on I'm only speculating:

It sounds like it goes down to some powersleep mode. And for some reason when it gets back, since its not going straight to your game (like Conan said worked flawlessly), it invalidates your DisplayDriver OR your program jumps on the GameLoop to fast (writing to the DisplayDriver if you are not the owner (i.e. has the focus) will also create this error).

So, I suggest you try three things:

1. Try adding a Sleep(1000) in Game::OnActivate before calling PocketPC::Resume(). It's a long shot but it could work.

2. Add a function to pocketpc.cpp that sets the global pointers to NULL (or 0) so you can try to reinitialize the DisplayDriver. Unfortunately there will be difficult to separate this behaviour from when the game only looses focus. And you don't want to create a new DisplayDriver every time (if that is even possible) because this will use up your memory eventually. Also, to be able to reinitialize you have to modify the Game interface and add a function here that does this for you (since all the stuff you need is private and you need a public or protected interface to use it).

3. Disable this owner info if that is what's causing the problem and you have no problem with normal suspend/resumes.

Not sure if this helped anyone. Sorry for a confusing and long post.

[Bapdude]

[Conan]