Monday, September 15, 2008

 

BDJ on PS3 impressions

JEmu2 on BDJ is now largely working on PS3.
It was really quite a hassle to get things going, but to be honest I'm not really sure it was worth it after all.

The problems with JEmu2 on PS3 are this:
* No sound
* Bad performance
* No VSync
* 60fps are drawn in JEmu2 but less are actually rendered
* Only one directional button gets registered at a time
* Only 2 action buttons available on PS3 controller

The sound problem might be solvable, but the rest is not as far as I can see; they seem to be limitations of the BDJ implementation on PS3. And from what I've read, the BDJ implementation on PS3 is actually the fastest and most complete of all Bluray players, so things don't look good.

The controller problems seem to be the worst to seriously consider BDJ as a gaming platform. "Only one directional button at a time" basically means that it's impossible to do diagonal movement, for example by pressing UP and RIGHT at the same time. This means most action games are out of the window.
The PS3 controller just acts as a Bluray remote here. So the analog sticks and triggers are not registered.

The JVM performance problem follows after the controller problem. The JVM seems to be an old fashioned interpreter, which is only helped by the PS3's CELL performance. A very wild guess would be that performance is comparable to a Sun HotSpot JVM on a 200-300MHz pentium (at the very most, but probably even less!).
The result is that JEmu2 struggles with many games. Don't even think about doing multi-CPU 16 bit games...

No VSync, and not having the ability to actually display 60fps don't help things either.

All is not lost though. BDJ might be a bad platform for emulation, it might still have some use for many game genres.
Considering all the above, it will be well suited for things like Chess and other board games, card games, some adventure games (point-and-click and such), any game that doesn't require fast animation or moving diagonally.
On the plus side, blitting images seems quite fast. Scaling small images to 1080p comes with no perceivable performance cost.

Labels: , , ,


Comments:
have you ever thought about porting jemu2 to android? That would be cool to and I think not hard, once you figured out how to do the controls
 
Porting JEmu2 to Android is a great idea, if java on Android is fast enough for it. I just need an Android phone to play around with. And some free time.
 
This comment has been removed by the author.
 
Hey!

Have you ever struggled out the problems
with javax.sound.sampled inavailability? Did the solution
with sound.bdmv help? at a first glance, the one that you've suggested @dev.java.net is expected to produce a noticeable delay...
 
I haven't worked on this anymore. There were too many issues besides sound to make it really viable. And wasn't the hack to run BD-Java via a USB stick on PS3 not disabled in more recent firmware versions?
 
Some notes:

- BD-J is supported on any bluray
player, not only on PS/3,
and I have a port of another emulator that runs on many players
from the disc well.

- I don't use flash card, and run
from BD-RE disc (in case of JEmu2 port of yours, the disc structure is a bit broken (at least PS/3
with most recent f/w claims that),
but some (software) players successfully load it.
 
I know BD-J is a BluRay standard and not specific to PS3, but PS3 is the only BluRay player I have :)

For me this BD-J development has been a bit of a painful experience:
* Lack of tools
* Bad simulator (often things that work on the sim don't work on the real thing)
* Lack of documentation

Some of that may be better now, but when I was playing with this, it was all very clunky indeed: Develop something, try it in the sim, put it on the USB, try on PS3 only find out that it just doesn't work without any access to a console or anything, rinse & repeat.

I can't even imagine how painful it would be if I'd insert another step of 'burn BD-R' in there.

And then the results were so underwhelming that I didn't really see the point in going any further. Especially the extremely limited controls (no diagonal movement is registered) were off-putting.

But then again, all of this development was based on this PS3 BDJ hack.
How did you set up your development environment? Any documentation you could recommend?
 
Hi Erik,

I assume that you have access
to BD-J/GEM/TV/PBP/CDC specs.

I know about two free tools:
- project hdcookbook provides
a number of must-to-have utilities.
It is free, and it's authors will
answers, and fix bugs in them if found.
- JavaME Platform SDK with BD support. It's probably not a best tool, but at least it is free.

- There is a number of BD players,
as H/W well as S/W with BD support.

While I attached a debugger to any of them, it was always true
that
1. System.out.println() is printing somwhere. In case of software bluray player it is either
a file, or can be seen with DebugView utility.

2. On h/w players you can dump your log directly to the screen, or
save it into Application Data Area (ADA). For PS/3 in particular where ADA is not a flash drive (idk), you'll have to develop another disc which will read the data from ADA and print it to the screen. Debugging scenario would be as follows:
- burn your disc
- start the disc you develop (1)
and do actions.
- eject (1), insert and run "log viewer" disc (2).

First thing you have to have is
to get access to as many as possible software players and
find for all of them where System.out.println()-s are printed to.
As soon as everything is working on
all of S/W players, it is time to polish
the disc by making sure it works on
PS/3, too. Well, you'll have to spend a couple of days on log viewer disc dev-t, and debugging the problems on PS/3, but you won't
need to mix dev-t and debugging.
In case of unbeatable problems
(e.g. you've faced to a bug in the player),
you can always act as you did with the sound support: ask the questions to forums.
 
>>Especially the extremely limited >>controls (no diagonal movement is >>registered) were off-putting

I suppose you mean that simultaneous
key presses are supported, right?

It is the reason for per-game
basis controls configuration.

as an example:
remote control kbd is

123
456
789
0
======
"1" pree will generate a key event
you'll turn it into two simultaneous "virtual" key presses
into the emulator. etc.

you can switch between different
remote control layouts using another key (e.g., colored keys).

If you recognized the game currently being played, you can
have prepackaged per-game keyboard
mappings and, on reading them, would let the user to switch between, e.g, by another colored key.
 
Hi bbk,

Thanks for sharing all that info.

I suppose using the numeric keypad of a remote could be used as a workaround, but it won't really solve everything.
And a bluray remote is not really meant as a gaming controller, so I imagine it's not really suitable for more demanding games.

When I was working on JEmu2-BDJ, I remember having a 'catch-all' block around the main loop, which would print the stack trace on screen. That kind of worked like lighting a match in pitch-black darkness...
But still, with the state of the simulator I used, it was all a bit trial and error to get things working on PS3.

But it's good to hear that things seem to have improved, so maybe I'll pick this up again at some point.

Thanks again!

Erik
 
Erik,

- Please note, PS/3 joystick is generating AWT events in their
impl.

- doing
try {
} catch(Throable eee) {
}

won't help if eee is origin
is the platform, on some players,
on PS/3 in particular.
In some (very short) time
after an exception is thrown,
player's OS will violently destroy the thread, and you won't see anything on the screen.

It's like OS is killing the process: good OS will be able to kill process despite it's wishes
to survive.
You only have guaranteed time
to flush and close log file in
that catchall block.

Good luck!

P.S. BTW, I tried to play you emulator on a player. Failed to
find the right ROM, may you please
drop a link at it?
 
I'd say a good JVM should never allow something to execute that could cause the OS to kill the JVM process. If that does happen, it's a bug of the JVM, or a bug in native code outside of the JVM's control (code called through JNI, bad drivers, a bug in the OS)
Even things like OutOfMemoryError or ThreadDeath can be catched.

Regarding JEmu2-BDJ, I've never released it (and I'd really have to look hard in my backups to find the sources actually).
The regular JEmu2 shouldn't work on a BluRay player as it's J2SE only.

Cheers,
Erik
 
Post a Comment

Links to this post:

Create a Link



<< Home

This page is powered by Blogger. Isn't yours?