Java for a game on Pc/Consoles in 2005?

Newbie & Debugging Questions
#1

Good morning.

A question to the veteran Java developers, please: say a small development studio (half of the developers know Java) plans to do a professional game (singleplayer, 3d graphics, not a first-person-shooter) with planned release date 2005.
Target platform: PC and the option to port the title to consoles, too (PS2, Gamecube, Xbox).

Would you advice them to use Java (with Jogl/Xith3d) as platform?

Personally, if there wasn’t this console option, I’d advice to them to use Java.
However the console option does worry me.

#2

The answer is… it’s a risk.

Currently there are no announced Java VMs for current or future game machines. I cannot speculate or comment on what we are doing about this inside of Sun beyond what I’ve already said. (That we recognize its an issue.)

Keep in mind that if you are planning on using the core game APIs (JOGL/JOAL/JInput) then those will have to be ported as well.

If you write a game in Java today you can certainly do PC, Linux and Mac. If you want to go to a console then you have 3 options:
(1) Hope that a Java VM (or compiler) is delivered for your target platform by the time you need it.
(2) Pressure the console maker to get a VM (only likely to be effective if you have a game thats already a hit that they want.)
(3) Port a VM yourself. (I know of one company that has actually done this for one console, but for legal reasons I can’t name them, sorry.)

#3

Thank you for the straight answer.
This is what I’ve been afraid of.

Since it’s a small development studio I don’t know what their chances are on the console market anyway (on the PC a small dev studios can well produce “long seller” titles; I’ve been involved in such one during the last years).
Still, probably they won’t forget about the console market option “just” because of Java. :frowning:

I’d love to suggest Java to them. They’d be so much more efficient. A pity. Let’s wait and see. Hope dies last.

#4

Couldn’t you also natively compile the bytecode for the console with a compiler like GCJ? Might require a bit of compiler tweaking, but at least the console philosophy means that you only have to tweak and test it for one platform.

#5

I don’t think a GCJ version is available to compile for consoles, or is it?

#6

[quote]I don’t think a GCJ version is available to compile for consoles, or is it?
[/quote]
Makes you go “Hmmm…”

#7

What processor is used on the console? The Gnu Compiler Collection supports cross-compiling for a lot of different processors.

/me goes Hmmmmm

#8

I suspect the primary issue is library support on those systems. Ina ddition to the JDK, which you could limit your use of, there is also run-time support for garbage collection, etc that would need to be ported.

But hey if one of you get GCJ compiling running code on a game machine, PLEASE let me know! :slight_smile: :slight_smile: :slight_smile:

#9

a quick google for “playstation gcc” throws up a lot of sites talking about creating your own toolchain using gcc tools. Most complete I found is “Not Yaroze”. This is for Playstation 1, but I did find a couple of sites talking about gcc for playstation 2. So from the angle of generating code it looks doable, as gcc and gcj use the same code generation. Like Jeff said, think the main problem would be library support.

#10

Is one of us in a position to actually try stuff? Who here has a console SDK?

As for libraries, LWJGL was supposed to be a candidate for porting to consoles… but it relies on OpenGL being on the console first…even OpenAL… Hmm… maybe X-Box is possible, but that isn’t nearly as interesting, since it is not much different from an ordinary PC as far as I know.

#11

LWJGL still relies on a core Java runtime (Garbage collection, exception handling, etc). In GCJ thats in your run-time library and I think is going to be your big snag.

#12

But can’t you just compile IT for that platform from the GNU sources?

#13

As a side note, the GP32 supports Java doesn’t it?

Kev

#14

[quote]I suspect the primary issue is library support on those systems. Ina ddition to the JDK, which you could limit your use of, there is also run-time support for garbage collection, etc that would need to be ported.
[/quote]
OpenGL is a problem on ps2 but as for run-time support, isn’t GCJ compiling some sort of JRE with your executable?
Creating bindings to use PS2’s native hardware could be an option though I suppose, if GCJ can compile for PS2.

#15

bit more googling and I’ve found gcc based compilers for the playstation 2 and the gamecube. So gcc can produce code for them. I would try this but the power supply for my linux box blew up last week, and my windows box aint set up to compile GCC from source. If someone else wants to try I’ll give what advice I can, as I’ve compiled it all from source a few times.

#16

[quote]But can’t you just compile IT for that platform from the GNU sources?
[/quote]
Only if that run-time was written to be totally portable. given how close it lives to the system layer, I have my doubts that you could do so efficiently, but maybe I’m wrong.

Keep in mind that down tehre you are dealing with system things like threading which WILL be different on different platforms.

#17

Not sure if this is relevant but if you google for: OpenGL PS2 you will find some references to a OpenGL1.2 PS2 port.

EG:
http://www.dataplus.co.jp/pdf-e/OpenGLPressRelease.pdf
and:
http://www.intercity.or.jp/middleware4ps2/OpenGL4ps2.html

Nothing real concrete, but a start anyhow…

#18

[quote]As a side note, the GP32 supports Java doesn’t it?

Kev
[/quote]
Not as standard unfortunately. The processor ( an ARM 920T, IIRC ) is one model below that which includes the Jazelle technology.

Though I am sure that i have seen a VM for the GP32 somewhere, and you might be able to use GCJ to cross-compile onto the ARM…

#19

[quote]Not sure if this is relevant but if you google for: OpenGL PS2 you will find some references to a OpenGL1.2 PS2 port.

EG:
http://www.dataplus.co.jp/pdf-e/OpenGLPressRelease.pdf
and:
http://www.intercity.or.jp/middleware4ps2/OpenGL4ps2.html

Nothing real concrete, but a start anyhow…
[/quote]
I heard performance is bad of the dataplus open GL library.

There’s also linux for PS2 and openGL running it. I don’t know about its performance though.

BTW, the Game Cube uses open GL as standard. A friend of mine is looking at how to write these discs as game cube dvd’s are not of a compatible format. IIRC the difference is something like they’re written from edge to center as opposed to center to edge and that it might require a hardware trick in your DVD burner, but he was not totally sure yet. Fortunately these small writable dvd’s are available.

Erik

#20

Hi again. Thanks for all your helpful responce in this thread and the “Reasons for a Java game” one (also to the guys at SUN). :slight_smile:

Let’s assume your crew’s programers would “just” do the desktop PC version of your game. One reason being that they have got no experiences with consoles. So basically you could use Java for this.

But… how could you meet the argument that the potential publisher could want your PC game to be as “console portable” as possible? (So that it could hinder your plan to use Java “just” for the desktop PC version?)

I’ve been under the impression that if you’re doing a C++ game, you can’t take the source code of the PC C++ version and use it for the PS2, Gamecube and Xbox version in a direct way. Even if you use a so called portable 3d-engine like Renderware. Things like IO, sound, and so on are (totally) different. Except Xbox maybe.
Furthermore the different consoles have a very different architecture.

Doesn’t this mean you’ve to re-write, maybe even re-architecture, large (?) parts of your game?
Or put in another way: don’t those development studios which port PC titles to consoles (or console titles to PC), do a kind of re-programming anyway? So that the argument “PC C++ game soure code is portable to console” is weak, too?

Any console programmer here? :slight_smile: Thanks.