Is BD-J really more complex than HDi??

[Whyser]

I was in a forum arguing about which is the better HD format (of course I was fighting for Blu-Ray), and I said that come Oct 31, HD DVD will have no more advantage in terms of features.

Disc space, streaming rate, overall video/audio quality, interactive features, copy protection, disc durability, I told him that Blu-Ray either equals or excels HD DVD in all aspects, and that it basically boiled down to which studios you would want to see your movies on. The only advantage HD DVD has is Paramount/Dreamworks/Universal, and the cost of the player.

But the guy kept countering the interactive features, telling me that HDi is much easier to program for compared to BD-J, and gave me two links:

http://www.pcworld.com/article/id,136253/article.html
http://www.economist.com/science/dis...ory_id=9689600

From the first:
"BD-Java is a programming language. The benefit is that it's very flexible. The drawback is that you may need 100 lines of BD-Java code. HDi is a relatively compact piece of code; one command can cover quite a bit of interactivity.

BD-Java is also more complex, so the possibility of errors is greater. And when BD players are put out, [there's the question of whether] they all support the scenarios as coded up from the low level. [Some of the early problems with BD-Java discs] were in part due to the complexity that BD-Java brings. From our point of view, HDi offers all of the flexibility we need, in practice, and it does so in a more simplified way and in a way that we feel leads to better compatibility, better reliability, and lower costs. "

From the second:
"Engineers who’ve worked with both formats say Blu-ray is a pig to program. While extremely flexible, its programming language, BD-Java, requires lots of low-level code for even the simplest of instructions. The highly skilled programmers needed to do the job don’t exactly grow on trees. And because of the program’s complexity, even the best produce their share of bug-ridden software.

By comparison, writing software for HD DVD using Microsoft’s HDi interactive technology is a doddle—with one simple command doing the task of scores of lines of BD-Java. More importantly, HDi is the key to HD DVD’s better navigation around menus, and its instinctive ability to interact with the outside world."

So what I ended up telling him was that these problems were only temporary. Once programmers are able to get a set of libraries developed for BD-J, HDi's advantage for ease of programming should diminish.

But he retorted that since it requires skilled programmers to do BD-J, it's going to cost more for a studio to develop, therefore it would not be as economical for them and thus HD DVD is the superior format when it comes to interactive features + low cost of programming.

My question is, is BD-J really THAT difficult to develop for?

[spam.curitiba]

I doubt it would be for a blu programmer...but for someone over in M$ offices it sure the hell would be.....

[kaliraver]

I would think its more flexable of a programming language compared to HDi. On top of that Java has been out for many years and should be easier to program for since more people should know it, compared to HDi.

[thrlride]

Originally Posted by kaliraver69

I would think its more flexable of a programming language compared to HDi. On top of that Java has been out for many years and should be easier to program for since more people should know it, compared to HDi.

Kinda like assembly vs c+

I really don't care about the special features so they can keep both.

[CptGreedle]

As BD-j is based on existing Java, ANY java programmer should be able to program for it. As HDi is based on new proprietary Micro$oft software, it will require new training to program for. If it is easier or not is not the point. Right now it might be easier, but the PS2 was a b!tch to program for back in the day, now its the best selling console ever! Once a decent library is built, it will be a synch to program for. It is more FUD, besides, consumers don't care how hard it is to program for, that is up to the developers to figure out.
If they think a java programmer can't make a bug-free program, no wonder they work for Micro$oft, home of Vista, XP, Zune, and all the other failed attempts at bug-free products.

[eat_me_cool]

Java is considered to be easy to program. Simpler than MS's C++ for instance, I know experienced programmers who simply gave up on it and went back to C.

The Dragons Lair programmer wrote a article about converting the game to BD-J. He had a few problems, but basically it was straight forward to do.

[Luis_A51]

While its true that HDDVD might be easier to program for, and that this along with replication costs, likely make them a slight bit cheaper to produce.

But what the hell does it matter if they dont sell? Unit cost isnt the be-all-end-all, volume is a huge factor as well. The small amount of money they *might* save with HDDVD is offset entirely by the extra revenue due to higher unit sales for BD.

Its nit-picking to the extreme. Next they're going to say red dye is cheaper than blue dye so since HDDVD cases are cheaper to produce then studios will choose HDDVD!

[fronn]

HDi is only easier in the sense that all the functions are already made and the libraries are there for you... all the functions you can ever use are there.

BD-J doesn't have the libraries pre-made... the person has to do it, but this gives greater flexibility and the obvious and ignored fact by MS and pals is once a studio or person creates those functions he essentially just made himself a library. BD-J is only difficult early on before a person has made the libraries... It's only a matter of time before the big studios have a library that'd be just as easy (possibly easier) to use than HDi and more flexible. It's also only a matter of time before a software company creates a library for consumers and/or studios.

It's patently false to say that BD-J is this difficult beast to conquer and will forever make BD's more expensive and time consuming to create. It's simply ignorance and part of why I can't take anything Amir says seriously -- he's so full of disingenuous information that it isn't even funny.

[WickyWoo]

HDi is essentially a scripting language like XML

BD-J is a full-on programming language. Once you have a base library of code for commmon functions that you can cut and paste, you only need to pull out the programmer for NEW stuff

Which once things get moving is about 10% of the titles moving through an authoring house. Look how cookie-cutter a lot of SPHE and Uni (on the hD side) titles are. They use what works and slap in new graphics

[owa]

Originally Posted by eat_me_cool

The Dragons Lair programmer wrote a article about converting the game to BD-J. He had a few problems, but basically it was straight forward to do.

I wonder if it was the increased flexibility of BD-j or some other reason for them having more features in the blu-ray version of Dragon's Lair? Edit: I'm asking...not trying to imply anything.

From the hidefdigest review...

Unfortunately, there is one major difference between the HD DVD and Blu-ray versions of 'Dragon's Lair' that, for me, is a deal-breaker in favor of the Blu-ray. Included on that release were five basic gameplay options that Digital Leisure added to the disc using BD-Java. You could customize such parameters as the number of lives, toggle off the text overlays that prompt your moves (a la the original arcade game), as well as select between "Home" and "Arcade" modes. Alas, not a single one of these options are included on the HD DVD. (Just to make sure I wasn't simply missing it on the disc's menu, I read through the entire documentation included with the disc, and unlike the Blu-ray, all mention of these options have been removed from the text as well.)

[spam.curitiba]

just wait until the studios start doing some kick sas stuff with bd-java.....and then see what the hd dvd fanboys say about hdi...

[Nick Graham]

Programmers have cited Java in general as being overly bloated (John Carmack being the last I can remember), but all in all I don't think one is that much better than the other in terms of what they are currently used for. These days what passes for super-cool interactivity is trivia games and video commentary, and I think it will stay that way until somebody like a Van Ling really breaks that box everybody is sticking themselves in and does something really cool with either one of them. BD-J seems to have more potential, but if I were a betting man I'd say both BD-J and HDi have a lot of potential no one has bothered tapping yet.

[mcy_999]

There are more than 5 million Java programmers out there. The BD-J for building interactivity applications are generally low end stuffs for the power programmers. But the gaming and disc publishing companies may not be equipped with power Java programmers. So it would take a little time to staff up those resources. But if you look far in the future, there won't be any limits for what the Blu-ray technology can do and evolve into. Expecially on the PS3, with its powerful 64-bit processor, ever increasing BD disc capacity and backed up by the true computing Java languge, the rest is just imagination. Then you look at the HD DVD world, everything is limited including its future.

[TauRus]

OP, these do not seem to tbe the words of actual programmers. Writing code is their bread and butter, the more complex codes they write the better, the more hours they can charge. I dealt with a few of those while managing some projects and I can tell you their reaction is typically quite opposite to what that guy was telling.

[kjack]

Originally Posted by Whyser

So what I ended up telling him was that these problems were only temporary. Once programmers are able to get a set of libraries developed for BD-J, HDi's advantage for ease of programming should diminish.

Who needs to build up their own library? Development tools are now available that use a drag-and-drop interface to auto-generate the code.

OpenCable (OCAP), DVB (MHP) and ATSC (ACAP) all use Java. ISDB for Japan just also adopted it, moving away from their XML-type design. So using BD-J further enables BD to fit in nicely with all the world-wide broadcast standarts. Many of the OCAP/MHP/ACAP suppliers are now offering BD-J modules for BD players.

[lymzy]

Hi Kjack,

What does Alco (Venturer, Trutech, Durabrand, ILO, Audiovox, and Magnavox) in your sig means?

Does it means those player all use the same reference design based on MS-BRCM 7440 SoC?
Thanks.

[supersix4]

Originally Posted by spam.curitiba

I doubt it would be for a blu programmer...but for someone over in M$ offices it sure the hell would be.....

yeah typical

[rpneuss]

Honestly guys this java stuff does nothing for me, no offense to the people that will utilize it. I think that it's good they're developing it, but I just want to watch movies with great transfers, encodes, soundtracks and bitrates. I've never payed any attention to special features.

[mastertang]

There is a program called VisualBasic (M$ i think makes it). It allows non programmers to program fairly simple applications through a simplified interface. HDDUD uses this idea, making it easy to make what seems like a complex menu system.

BDJ is better in my mind because its only limits are that of the hardware. It's possible that something will be developed on blu that the other guys can't replicate with their simplified interface. JAVA is a free language as well. Microsoft sure does hate things it can't control.

[ps3andlovinit]

Originally Posted by kjack

Who needs to build up their own library? Development tools are now available that use a drag-and-drop interface to auto-generate the code.

OpenCable (OCAP), DVB (MHP) and ATSC (ACAP) all use Java. ISDB for Japan just also adopted it, moving away from their XML-type design. So using BD-J further enables BD to fit in nicely with all the world-wide broadcast standarts. Many of the OCAP/MHP/ACAP suppliers are now offering BD-J modules for BD players.

Thanks for shedding light on the importance of standards for ease of interoperability ... and ultimately development re-use...