Pretty neat.



From what is presented in the TDK, here is what I find compelling (and likely to implement in our game):



1. Display current battery life.

2. Display network signal strength.

3. Support for multiple processors.



Although I see the benefit of scaling usage based on the power source,
that would require an architecture change expensive enough that it
doesn't feel worthwhile. Even games which provide customization of the
rendering quality will typically try to render at full speed - they
usually aren't designed with run-time throttling in mind.



--------



There are several changes to your sample application that could be made to more accurately demonstrate what you are advocating.



1. Display frame rate for the sample.

2. Cap frame rate at 30fps if you detect that the power source is a battery.



3. Even though the physics in the sample is run in a separate thread,
there is no asynchronous operation. There are three alternate
implementations that you could provide which would truly support
multiple processors:



Easiest (but worst) - Utilize 2 threads for physics rather than 1.
Split the number of spheres to update between the two threads. This
will allow each CPU to process a portion of the physics asynchronously.
Although this would not translate well to a practical implementation
for a game (since most objects need to interact with other objects in
the scene during collision response), it would at least demonstrate an
increase in frame rate for machines with multiple processors.



Better - Reverse the order of operations between render and physics.
This will allow the physics code to execute while the graphics device
processes queued calls to draw (which will eventually block the UI
thread on Present). This translates well into an easy to implement
optimization for most games, but will probably not affect the frame
rate much for your sample, since your vertex shader is not very
expensive to execute. Also, this doesn't exactly demonstrate support
for multiple cpu's, it just shows asynchronous operation between the
gpu and the cpu.



Best - Maintain two sets of position data for the spheres. At the
beginning of each frame copy from the "Live" set to the "Render" set.
Execute both Physics thread and Render at the same time, only blocking
prior to end of the frame to wait for both to finish. This would
demonstrate true multi-processor usage.



Side note: The UI controls & text on the right are rendering
partially offscreen, and the application crashes when I toggle the
check box at the bottom.



-Isaac Squires

http://www.SiderealFury.com/

Between design changes in our project, and discussion during today's live TDK chat, I am interested learning more about methods to monitor and control power consumption. Our game is being designed to run for long periods of time (existing in the background while the user performs other tasks), so it would be beneficial to throttle operations even when the user is not running on battery power. Is there a resource available which will enumerate common hardware which add to CPU / Power overhead, as well as mechanisms to control their activity?

I'm also thinking about some creative ways to handle wireless connectivity loss.

Thank you for hosting today's chat, I found it helpful.

-Isaac Squires
http://www.SiderealFury.com/

Thank you to all the participants in the online chat on the 19th. Excellent questions and suggestions for creative uses of the TDK. The transcript has been posted. Take a look and let us know what you think.

http://www3.intel.com/cd/ids/developer/asmo-na/eng/325879.htm

Nice API. Pity it only support M$. Any plans to port the TDK to linux?

thx,

bob

Porting the TDK to linux may or may not support Intel chips, but porting the TDK to the Mac absolutely targets an Intel only platform. It seems to me that would be in Intel's benefit. Please consider supporting the Mac platform as many people would rather play games on the Mac OS X instead of Windows, if only there were more games. You can help with this. Respectfully, Douglas W. Goodall

With regard to porting, we recently spoke to one of our othercontacts for the TDK, who agreed that the Laptop Gaming TDK can be ported to Linux* with minimal effort. They said porting to MacOS* is likely also not a problemsince most of theAPIsused are generic, and any Windows*-specific APIs should have an equivalent in MacOS.A Java*-based API should also work.

==

Lexi S.

IntelSoftware NetworkSupport

http://www.intel.com/software

Contact us