How does GLBasic impact battery life on Mobile Devices?

[turnerb]

Disclaimer - I am completely new to GLBasic.  My questions might be stupid and I have not yet fully investigated how to create a full game with GLBasic.  I wont be offended if you tell me to go off and study some more before asking stupid questions

It appears to me that all GLBasic applications are all running an infinite loop, which of course is very common and necessary in a game. 

This would appear to me to mean that you are effectively pegging the CPU anytime you have a GLBasic application running.  To test this theory, I ran the glbox2dtest.exe with task manager running on a Windows Box.  glbox2dtest.exe consistently showed 2-3% CPU usage (I am on a 24 Hyper-threaded machine) even after the boxes had finished dropping, it was basically "just sitting there waiting to respond to a mouse event" and consuming just as many CPU cycles as when it had to animate things on the screen. 

I think everyone accepts that games will suck your battery life when you are playing them, but I think this also means that if you were just sitting at the start menu of a game not animating anything or playing any sound, it would also suck the battery life out of your mobile device just as fast.  This is probably not an issue on iPhone/iPad because if you are not playing the game, the application cant really consume CPU cycles because iOS suspends that thread.  However, on more advanced devices like my beloved HP Touchpad that does allow true multi-tasking, and possibly more recent Android devices, it seems like this might be a problem.

An example would be someone writing a nice 3D Sudoku or Mahjong game in GLBasic.  These are games that dont neccesarily require you to give them 100% of your attention.  On the Touchpad, I can be playing a game like that written in GLBasic and switch to email, web browsing, etc... and not come back to the game for 30 minutes or so.  I would expect that if I did this, I might find my battery to be rapidly depleted.

Does anyone have any comments as to the validity of my concern, and possibly any way to make GLBasic stop or slow down the game loop to conserve battery life when waiting for the user to do something?

Thanks

[Ian Price]

I'm writing a Match3 game for Touchpad and I test/play it for long periods off and on. My battery life is excellent - in over two weeks I've only charged the TP twice and neither time did it really need charging (last time it was just under 50% capacity).

I've also played my Pre games (including a Sodoku type game, Ken2X) on my TP which scale up.

I'm certainly not worried about battery life due to playing/using games/apps - either GLB or other.

[matchy]

Why do glb newbies always introduce themselves down then shoot from the hip? Anyhow...

I don't think only games are an issue for battery life, even on the title menu but it's something to important to note, at least for pda server apps, which may not require any graphic output.
Perhaps there's some inline c code to cater for cycle resting and threading and all that. 

[spicypixel]

Why do glb newbies always introduce themselves down then shoot from the hip? Anyhow...

I think that's a bit harsh Matchy, it's a legitimate question asking about technical aspects of GLBasic that may have had a command within the language to deal with cpu processing, an Idle state so to speak, or if GLB deals with it automatically. Harsh lol

[matchy]

spicypixel, talk to me if you have a non-technical issue rather that in third person and note that I'm simply responding to first line with a follow up on the techie stuff. sheesh gimme a break! 

Disclaimer - I am completely new to GLBasic.  My questions might be stupid and I have not yet fully investigated how to create a full game with GLBasic.  I wont be offended if you tell me to go off and study some more before asking stupid questions

[Moebius]

Sure most programs use an infinite loop, but idling is built into the 'SHOWSCREEN' command - it keeps to the framrate you specify.  GLB handles losing focus as well (see 'GLB_ON_PAUSE', 'GLB_ON_RESUME'), which you can handle any way you like in your code.  It's really the programmer's problem if it consumes energy whilst idling ( ) and the samples aren't really concerned with that.

[kanonet]

For reducing cpu-load i recommand checking (and using) the command SLEEP. In my opinion this is the best way...

[bigsofty]

+1 for "SLEEP"

[Kitty Hello]

Limitfps can idle the cpu. Hibernate even more.

[MrTAToad]

Will HIBERNATE on WebOS, iOS and Android now, or does it do thing ?

[Kitty Hello]

HIBERNATE checks for key/mouse/joystick events. If there's none, it will SLEEP for (IIRC) 15 ms and loop.

[Wampus]

I don't know if its better or worse for battery life but on iOS I like using LIMITFPS 60 in conjunction with SLEEP. The idea is to be able to frameskip if things are running slow.

Every screen refresh I measure how long it took to draw the entire screen using GETTIMERALL(). After that I run the game mechanics loop for as many steps as it takes to catch up. Ideally that loop should be just once most of the time, unless something is slowing the device (e.g. multitasking) or the hardware is very old. Whatever gap of time is left over I use SLEEP for. Seems to work well. Setting the frame time to 16.666 I get ≈ 30 FPS on 2nd gen devices and ≈ 60 FPS on 3rd gen devices and up. Seems to preserve battery well enough too.

[Kitty Hello]

You can implement frameskip yourself, if you put all "draw" commands in a separate function.