Tala

Quote:

1) "Thread priorities" -- The Windows OS is prioritizing threads and balancing what it thinks should be running.. this is causing slowdowns at random times in the engine display or runtime or the like, so bear with me. Let me know how it runs on your device, and let me know what your device is.. over a few alphas hopefully we can find the right level of OS tuning to make it run well.

I think you have another problem, than just thread priorities. Usually there is nothing "running" in the background, that needs to be scheduled by the OS.
Also do you use GAPI for Input?

Regarding the screenshot util, just use the code i wrote for PocketSNES, which i posted on the zodiacgamer boards. Just replace 640 with 320 and 480 with 240 respectively. Set the global framebuffer pointer to the address GAPI returns. Thats it.

Tala

ps. Nice work so far :)

skeezix

I'm experimenting with different techniques for Pocket PC since of course I've not done a lot on the platform yet. The BOR code is monolithin and not event driven, so I've gotten a few versions .. 1) A two thread version with the UI/WndProc as one thread receiving the IO events and such, and the game engine backgrounf thread doing the display and chugging away. This way I can handle input in one thread and the other thread can run as it expects. Yhis is the one I let out last night.. 2) Altered the BOR engine code so that its re-entrant so I can just call its various state machines in the WM_PAINT or the like, so I Can run as one thread.

Its a shame the thrader seams to be whacko on the platform since of course thats much easier than butchering the code up just to port it :) ie: Just having the two threads running (not much else going on in backgorund) introduces a pretty high performance cost.. ie: With one thread, the game comes up in a second or two, but using two threads it could be 15-90 seconds depending on the priority you assign.

ie: Setting the main game engine thread to low priority and the UI to high, the game engine takes minutes to come up, despite the fact the UI thread is actually doing nothing. In that case, the switcher should bring the lower priority threead to an elevated prioritiy on its own one woudl think (like a desktop OS does)..

So if I set them the same priority, you can see the animaiton go smooth for a moment, then chug for a moment, and then smooth .. just round robin for a second or two at a time. Setting the engine to higher so it loads fast and runs smooth causes it to work well, but then the input form the other thread goes out of sync or gets lost.

So ultimately I may likely have to go for a single threaded approach, since it keeps things nicely under control and timed, but its a shame since threads are ideal for this sort of thing normally, but perhaps on WinCE they're better suited to asynchronous background jobs... but of course I've not done much on WinCE platforms so theres lots of "little things" to look into.

On Palm OS one can call functions to seek through the event queue without having to wait on an event system to call you back. In win32 theres PeekEvent and such, so I'll check if those are available in Pocket PC's world.. if so, then I could just have an event-loop-checker in engine to look for pen-down events and such.

(ie: Theres the KeyGetStataAsync or whatever it was called that can check button-downs in real time, so that should work. So far its not seamed to work but perhaps its due to the threading oddities so far but I'm assuming it could work and will do some tests in the non-threaded version I'm working on. But is there a way to detect pen-down and pen-down-location without waiting on the event loop or WndProc or the like? That would be handy and I could just ignbore the event system as the engine was designed originally.)

I'll fiddle around a bit anyway until I find the right balance for this sort of codebase .. either hacking the code up, or finding an approach that works within the codes structure. Its always fun playing on new platforms :) (It was very weird to find out that if a printf() went off and Pocket Console was installed then it woudl launch the console, which would interupt GAPI and stay in high res. That took awhile to find for instance... you never know :)

jeff

skeezix

TalynOne -- Try the big 50MB "Beats of Rage" mod (the one the engine was made for) .. its got a lot of animation and is really well done. Its still not playable of course but I'll work on that..

BTW, I'll let the source out once I get somewhere .. just having fun with it right now, but I'll put it all in a bit. Perhaps once I get it smooth I can summarize the approach rational in case its useful to others.. since trying a half dozen methods to do things due to OS oddities is wasteful and may be avoidable to others given the experiences garnered so far. (I'm sure the info is all around, but googling around is an enormous time killer as well :P)

jeff

Tala

Quote:

ie: Setting the main game engine thread to low priority and the UI to high, the game engine takes minutes to come up, despite the fact the UI thread is actually doing nothing. In that case, the switcher should bring the lower priority threead to an elevated prioritiy on its own one woudl think (like a desktop OS does)..

Some comments:

-Do not set them to different priorities, as this will make the lower priority thread only execute if the high priority thread has nothing to do. In particular giving the worker thread high priority is very harmful, obviously.
-Apparently there is something wrong with your UI thread. If it were doing nothing, it would not get processing time at all.
-Use GetMessage instead of PeekMessage, which makes the OS immediatly switch to other threads if the queue is empty. Using PeekMessage in a two-thread implementation is harmful.
In a one-thread implementation you should use PeekMessage of course.
-Use RemoteSpy to check the messages your UI thread is receiving. Messages, which are not handled correcly are re-issued by the OS.
-The OS is sorting the messages in the queue. Thus messages, which arrive later are not neccesarily later in the queue. For instance messages related to user input have higher priority than timer messages.

I think you are looking in the wrong direction. There is nothing wrong with the WinCE multithreading system. It works like any other system (Unix/Desktop Windows etc.) It is most likely your code, which is pulling performance down.

Tala

Tala

Quote:

But is there a way to detect pen-down and pen-down-location without waiting on the event loop or WndProc or the like? That would be handy and I could just ignbore the event system as the engine was designed originally.)

You are actually not waiting on WndProc. WndProc is almost directly called by DispatchMessage().
What i suggest you to do for a one-thread version is either:

while (PeekMessage(&msg, NULL, 0, 0)) DispatchMessage(&msg);

or possibly

if (PeekMessage(&msg, NULL, 0, 0)) DispatchMessage(&msg);

You just have to insert above code for instance just after the blit to the frontbuffer to make sure its exactly executed one time per frame.
Message handling is still done in your WndProc, which is fine.

Tala

skeezix

Yep, that was what I was thinking.. just so far experimenting with lots of other options instead to see how they worked out. ie: If you don't need screen taps, you could just skip the event handling but I wonder how the OS deals with that (if theres a number of events queueing up etc..). Just googling for PeekMessage doesn't return much useful so I'd not had time to look for the event functions, so thanks for pointing 'em out. (I really didn't want to go dig out my win32 SDK form 1995 before MFC came in and pissed all over everything :P)

I'll swap back to single threaded and see if that'll take care of it. If so, it'll be more like every other OS.. thankfully ;)

jeff

TalynOne

Hi skeezix,

Here's the first alpha report # 2.

Ok, I just tried the 50MB PAK file that comes with the DOS distribution of BOR.

As you've mentioned before, a loading screen would be good, it seems frozen when launched, since you see nothing happen but the screen turn funny because of GAPI/GAPI tweak. I figured it was just taking a lot longer to load since it's a much bigger PAK file. Took about 2+ minutes to load on my X50V in performance mode (I'll time it next time if you want).

The Senile Team intro was choppy. Seems to be slow and fast in spurts.

Also it takes a while to go from the main menu to the start game "Loading..." screen (before the character selection screen). I don't know if it's because of a delay in reading my button presses or if it just needs a pocketpc "wait" animation at that point.

There's such a big delay between registering button presses I'm not quite sure which button does what. I just keep pressing different buttons until something happens.

The "loading.." screen after the character selection screen takes about 10 minutes to load.

Here's a screenshot I was barely able to get using GetPDAScreen through ActiveSync:




PDA Stats:

PDA Model: Axim X50V (A03)
GAPI Tweak?: Yes, version 1.1.
Background Apps: Spb Pocket Plus 2.5, Spb Weather 1.1, Resco File Explorer 5.14, the latest beta Wisbar running in the background.
CPU Mode: Auto

skeezix

Alright, very sweet; got a moment and so put in the GetMessage/DispatchMessage bit and she works great, so no more control problems or thread-sluggishness. Thanks Tala :)

I'll do a few quick improvements if I can manage a moment and let it out :)

jeff

skeezix

By request I uploaded the current alpha to..

http://www.codejedi.com/bor/binaries/borce002alpha.zip

I'll likely have an alpha3 tonight or tomorrow that is smarter about pak names or the like, but this one runs very nicely and is playable if you can manage the buttons.

Hopefully next alpha I'll get screen taps for fire/jump/special in there.

Works very nicely with all BOR mods I've thrown at it (which it should, since I revamped the engine for Palm OS anyway :P)

jeff

skeezix

TalynOne -- since you're here, fire up alpha2. You'll love it :)

I'll get some finger-tapping-fire action in soon .. move on the left, fire on the right.. thats how its meant to be played :)

jeff

edit: Actually, this totally rocks with screen tapping doing attack/jump/special, so alpha3 later tonight.

Shadownova

So far BOR will only run on the Axim x50v i guess cause it will not run at all on my Ipaq Rx3715 with a 256 Sd Card and a 400mhz processor. Ill try your 3rd alpha when you get it up.

skeezix

I don't do anything Axim specific in there, so I should think it'd run anywhere; make sure you've got enough memory set up, and make sure you've followed the readme carefully since it is very picky about filenames and pahts right now. (ie: It needs to find a PAK file to run, and it has to be in exactly the right place and name, for now.)

jeff

Shadownova

Ok i got it to run. The problem was that i put it on my sd card which my ipaq calls that folder Storage Card instead of SD Card. So i made a folder called SD Card and then it worked. I tried to change the name of my "Storage Card" to "Sd Card" but no luck. I will try and change the name later. So far i got it up and running on my Ipaq Rx3715 with a 400mhz processor with no programs in the background. It runs extremely smooth and perfect on mine (no sound). Ill mess around with my storage card and see if i can get the original running. Great port. I look foward to your screen contols.

skeezix

OKay, hacking aay like mad (before the wife gets home .. ;)

Grab alpha 3 .. hopefully she works for everyone else as well as she does for me!

Check the readme, but it should be very easy to install; if you're new, just copy the zip file contents to some place on SD or CF or RAM or the like. If you're updating from alpha1 or alpha2, you'll have to rename your pak file to bor.pak instead of vbor_cast.pak, but you can at least put it anywhere you like now (as long as the .exe is in the same place.)

Get it here:
http://www.codejedi.com/bor/binaries/borce003alpha.zip

Changelog:
alpha 003
---------
CHG: Debug logging is currently 'on' (see /zotlog.txt)
NEW: Tapping in 'bottom right' of landscape (controls on the left) and its
'attack'; tap in top right and its 'jump'; tap left half of screen and
its 'special'. Playing with left hand on d-pad, and right doing thum-taps
is slick as heck.
CHG: 3rd hardware button should act as a 'quit' button that just kills the
engine after a few moments (use the left-half of screen tap to do Special)
CHG: It now expects to find the pak file as "bor.pak" in the same location
as the borce2.exe program file is; ie: You can put the thing anywhere you
like now, but the pak file and the program have to be in the same place
and the pak file is bor.pak (not vbor_cast.pak like it was)
- I will soon add a PAK picker to make this easier .. it'll look in
the same place as the .exe, but give you a menu to choose from

alpha 002
---------
CHG: Event handler overhaul (thanks Tala for the tip) and now she runs *great*.
Full speed, no sluggishness as threads flip, etc.
CHG: Added some hardware buttons for attack/jump..

Enjoy!

Let me know what you think!

jeff

skeezix

shadownova -- alpha3 should sort you right out then, since it doesn't assume the /SD Card/ path anymore :)

Try moving it back to Storage Card and let me know :)

jeff