Gimbal Games Inc.: Project Ishido

[gimbal]

Yep, I'm back again. Not with project TwinTris however, I decided that I needed a little test game in between to test out my Hwpda 2.0 framework (which allows me to build games for windows desktops and pocketpc devices with no changes in the game source code). So I decided upon a little game I have done in the past, only then it was a dos-game: Ishido - the Way of Stones.

http://hol.abime.net/2671

Visit the very basic project page here to get the desktop version of the game:

http://www.xs4all.nl/~gimbal/projects/ishido.htm

I started development on this little game only two days ago and now I am calling it finished, so I am fairly happy with how my framework turned out! Alas, on the PDA there are still some major issues I need to resolve, but at least I have seen the game work on it.

Of course the game is nowhere near as complete as the Amiga original, there is only one board and one stoneset and there is no 'victory' screen, but other than that I am very satisfied.

As for the technical details, it should work on any windows 2000 / windows XP / windows XP64 machine, but most likely not on Vista.

[eLowar]

It does run on Vista (32-bit version on Core2 Duo), although it makes my CPU run at 100% (on one core at least). I'd love to give more debugging information, but I can't think of what else could possibly be related right now and I don't feel like typing down my whole system specs right now either, although I don't mind if you want me to.

I could test on XP on a different machine, but that wouldn't be the same machine. And I assume you've tested it on XP or 2000 yourself, right?

Anyway, if I can help you diagnose the issue in any way (assuming you care ), let me know.

[gimbal]

I know that problem, I can't find a way to do the game loop so it does not use 100% cpu (it's not really horrible, the game uses the resources that are left, not ALL of it). Every article and book covering win32 game loops I've seen does it my way, or rather I do it their way.

I wouldn't have expected it to work on vista because I use DirectDraw which has a terribly buggy implementation on that OS :s

[eLowar]

Originally Posted by gimbal

(it's not really horrible, the game uses the resources that are left, not ALL of it).

Umm, well, it eventually raises the CPU temperature by about 20°C and causes the CPU and case fans to run rather fast and hence loudly.

[pbareges]

by the way to all our beloved whd coders (after winter games -and waiting for player manager - everything is now possible!!!), this great game still need to be whdified!!thanks in advance guys!

[gimbal]

Umm, well, it eventually raises the CPU temperature by about 20°C and causes the CPU and case fans to run rather fast and hence loudly

Yes if you put it that way, it IS horrible. Well what I can do is look at open source games and "learn" from the code how to fix this problem...

[Shoonay]

Works on Vista x64 here, and "only" takes about 20% from the 1st and 50% of the 2nd core

[eLowar]

Maybe using a timer instead of a tight loop would solve the problem?

Without animation, wouldn't it be enough to only react to input events (and not run anything when idle)?

I assume you're essentially doing this? http://en.wikipedia.org/wiki/Busy_waiting

[gimbal]

well I tried to fix it with Sleep (and a higher resolution timer): I calculate the amount of milliseconds I am doing nothing (nextframetick - currenttick) and then I Sleep() for that amount of time; when I log the times I do that, I see very respectful results; the game takes about 2 or 3 milliseconds to do updating and blitting (on my dual core) and the rest of the time is spent sleeping...

but the cpu usage is STILL 50% on my system :s :s (it was already 50% even without these changes)

[eLowar]

Hmm, I'm out of generic ideas, except "restructure it".

You don't have to redraw unless the image got damaged or there's something actually new to draw, do you? Couldn't you just wait for the next input event or redraw event then and do nothing at all in between?

I'll admit I don't know anything about that framework you're using, or much about raw Windows game programming for that matter. That's just approximately what I'd do in frameworks I'm familiar with.

[gimbal]

the problem is not redrawing, that is only done 'x' times a second (I limited it to 30 because I do want fast response to input, AI updating, etc. although that is not applied to this game). The problem is that I cannot seem to get the application to give up the remaining time that it is doing absolutely nothing. The basic structure is this:

- look for windows messages
- if there are none:
if(time_to_update)
update game state
if(time_to_render)
blit frame
else
Sleep(time_to_sleep)

time_to_sleep is based on the amount of milliseconds I have to skip before it is time to render the next frame, which is every 30 milliseconds in this case. The app is actually sleeping for around 30ms, but the CPU usage is still maxed :s


*UPDATE*
okay... I changed to:

- look for windows messages
- if there are none:
if(time_to_update)
update game state
else
Sleep(time_to_sleep)

if(time_to_render)
blit frame

and now the cpu resource usage stays at 6%.... I uploaded this new version, try it out please!

[ganralf]

Did you try MsgWaitForMultipleObjects() instead of Sleep()? You can pass your Windows Handle and a timeout (time_to_sleep). Should improve both responsiveness and cpu usage.

[eLowar]

Originally Posted by ganralf

Did you try MsgWaitForMultipleObjects() instead of Sleep()? You can pass your Windows Handle and a timeout (time_to_sleep). Should improve both responsiveness and cpu usage.

Yeah, that's the kind of thing I had in mind. Here's a real link: http://msdn2.microsoft.com/en-us/lib...42(VS.85).aspx

http://msgwaitformultipleobjects/ doesn't seem to exist

[ganralf]

Oops. I should better prove read. Thanks for correcting.

[gimbal]

Just wanted to mention a fun fact: I have implemented the HQ2X, HQ3X and HQ4X scale filters into the framework, in the hope of not only supporting larger window sizes than 640*480, but also keeping the graphics a little smoothed when scaled up 3 or 4 times. For Ishido it does not work so well, but I can guess for other games it can work nicely. See the picture below for a screenshot of the HQ3X filter, I have not uploaded a new version yet (need to integrate scale type selection into the setup box).

http://www.xs4all.nl/~gimbal/project...o/screen06.png