Skip to main content

Issue with remote colored buttons

4 replies [Last post]
joshw
Offline
Joined: 2008-07-28
Points: 0

I'm trying to implement the color buttons in my current GRIN project.

ex:
rc_handler key_pressed H:ColorB
{ blue }
execute {
java_command [[ XLET_ONLY_[[
System.out.println ("Color key Blue activated");
]] ]]
}
;

On my cyberlink software players, the keys yellow and blue are behaving correctly, but I find that on my PS3 and a Panasonic BD50 the colors activated are reversed. Blue activating Yellow, Yellow activating Blue. Has anyone else experienced this anomaly? Looks like there could be a discrepancy between PowerDVD and other commercial players, and the GRIN key handling is correct to the Cyberlink's.

thanks,

Josh

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
hooligancat
Offline
Joined: 2009-10-20
Points: 0

I know this thread is a little old, but is testing the hue of the colored buttons still the recommended approach to map the colors accurately?

Thanks

Bill Foote

bd-j-dev@mobileandembedded.org wrote:
> I'm trying to implement the color buttons in my current GRIN project.
>
> ex:
> rc_handler key_pressed H:ColorB
> { blue }
> execute {
> java_command [[ XLET_ONLY_[[
> System.out.println ("Color key Blue activated");
> ]] ]]
> }
> ;
>
> On my cyberlink software players, the keys yellow and blue are behaving correctly, but I find that on my PS3 and a Panasonic BD50 the colors activated are reversed. Blue activating Yellow, Yellow activating Blue. Has anyone else experienced this anomaly? Looks like there could be a discrepancy between PowerDVD and other commercial players, and the GRIN key handling is correct to the Cyberlink's.
>
> thanks,
>
> Josh

Hi Josh,

That's covered in the HD cookbook (the actual book), page
19-4, under "Those Crazy Color Keys". To assign the keys
by color, one needs to use a HAVi API, like Sample code 19.2
does. That's not included in the GRIN library itself, partly
because we didn't want GRIN to have a dependency on HAVi, but
provision is made for an Xlet to hook that code in.

I should mention that sample code 19.2 might be a bit overkill, since
subsequent to the book's publication, the BDA added a requirement
that the HAVi API return exact color values. The whole fuzzy match
on hue isn't necessary for players that obey the enhanced spec. That
said, I'd want to do extensive player testing before counting on that
spec requirement having been implemented everywhere that matters; all
things considered, it's probably worth it to be conservative, and
add the tiny bit of code for the fuzzy match.

I just added a reference in the javadocs for AssetFinder to draw the link
between the AssetFinder method and the algorithm in the cookbook --
see (the new) com.hdcookbook.grin.util.AssetFinder,
under getColorKeyCodeHelper(), which now says this:

/**
* Get the key code for the given color key. Xlets may override
* this to do an intelligent assignment of the color keys.
* See the HD cookbook page 19-4, "Those Crazy Color Keys" for an
* algorithm.
*
* @param c A color that is == to one of the standard
* constants Color.red, Color.green, Color.yellow
* or Color.blue.
*
* @return A HAVi key code in the range 403..406 inclusive
**/
public static int getColorKeyCode(Color c) {

Thanks for pointing this out!

Also, I just filed
https://hdcookbook.dev.java.net/issues/show_bug.cgi?id=127 ... Before
too long, We'll have an implementation of that algorithm in
xlets/grin_samples/GenericGame .

Oh - by the way - no real need for the XLET_ONLY_[[ here. In fact,
I'd recommend:

rc_handler key_pressed H:ColorB
{ blue }
execute {
java_command [[
Debug.println ("Color key Blue activated");
]]
}
;

That way, you also get the println when you run under grinview.
Also, by using com.hdcookbook.grin.util.Debug, the debug output gets
redirected to the debug log if you run the show file using GenericGame...
That's a pretty new feature, but if you run a show that way (which should be
pretty simple to set up -- see GrinBunny for a model), then the popup menu
button gives you a debug screen will some pretty useful stuff, like a debug
log (that you can also get via telnet if you want), the ability to change
the framerate on the fly, and "debug draw" mode that shows you the areas of
the screen drawn to in each frame of animation.

We really, really need to write some top-level documentation for this stuff...
Soon! :-)

Cheers,

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

joshw
Offline
Joined: 2008-07-28
Points: 0

thanks for your help again Bill.

-Josh

billf
Offline
Joined: 2004-02-13
Points: 0

Just to follow up on this...

Code that implements the fancy HD cookbook algorithm to assign the color keys by the hue values reported by the HAVi API has just been put back. It's not part of the core GRIN library, however. That's because we want to keep BD specifics out of the GRIN core; also, it's really nice that GRIN can run on desktop Java now, since it has no HAVi dependencies.

The place to find the implementation is in GenericGame, that is, xlets/grin_samples/GenericGame. In the course of committing the algorithm to code, I added two errata to the HD cookbook, too! See http://hdcookbook.com/errata for chapter 19, if you're curious.

By the way, GenericGame has evolved into a nice little framework for building simple Java-based disc images. As long as your disc fits the profile, you just need to create a new directory with a couple of standard sub-directories, copy a build.xml file, and populate a vars.properties file with a few settings, and voilà! A disc image, complete with desktop emulation via GrinView, a deployment version of the xlet, and a debug version of the xlet that includes two ways of getting to the debug log.

See xlets/grin_samples/GenericGame, starting with README.txt for details.

Cheers,

Bill