Java for a game on Pc/Consoles in 2005?

Newbie & Debugging Questions
#21

Of course java programs can be rewritten to C++ for a console, but I suppose it will take much more effort than porting a C++ program to a console.
A very large part of the C++ code will be game logic which can probably be quite easily ported to another platform.
With rewriting a java program to C++, you’d also have to do your own memory management where it’s done automatically in java by the garbage collector, for one thing. And then there’s also the extensive functionality ‘built in’ the JRE you’d either have to avoid to get it to port more easily, or you’d have to find C++ libraries that might behave slightly differently which might in turn introduce difficult to track down bugs.
Of course it can all be done but it will definitely take more effort. You might wonder if it’s worth it to avoid C++ to program in java only to translate it to C++ again to get it to work on consoles… Maybe it is, but I doubt if there’s any experience with it and you will probably have a hard time defending the idea to a development team consisting of mostly C++ developers :-/

Erik

#22

[quote]A very large part of the C++ code will be game logic which can probably be quite easily ported to another platform.
[/quote]
Say you’d be using some kind of scripting language inside C++ for the PC version’s AI (which you’d solve in another way, also elegantly, within Java): would this “C++ plus a script language” be portable to consoles, too, in an easy way?
In similar games aprox 1/3 of the entire game can consist of the AI part.

[quote]With rewriting a java program to C++, you’d also have to do your own memory management where it’s done automatically in java by the garbage collector, for one thing. And then there’s also the extensive functionality ‘built in’ the JRE you’d either have to avoid to get it to port more easily, or you’d have to find C++ libraries that might behave slightly differently which might in turn introduce difficult to track down bugs.
[/quote]
All the things I love with Java and can’t stand anymore with C++… Sigh.

[quote]Of course it can all be done but it will definitely take more effort. You might wonder if it’s worth it to avoid C++ to program in java only to translate it to C++ again to get it to work on consoles…[quote]
As said, my mentioned crew’s programmers won’t do the console port anyway.
I’m evaluating this “C++ to console” porting option just for the sake of the potential publisher.

[quote]Maybe it is, but I doubt if there’s any experience with it and you will probably have a hard time defending the idea to a development team consisting of mostly C++ developers :-/
[/quote]
Yes, that’s a huge problem.
Still one day they’ll have to leave C++ anyway because it’s no modern language.
(Those Visual Studio C++ fans out there will be amazed how fast Micorsoft will let C++ die for the sake of their Java clone named .NET/C#).

PS: Please don’t wonder why I track the topic so persistently. It’s just: the game’s no first-person-shooter action game, and anything it needed I can imagine to be done in Java for the desktop PC version. It would be such a nice opportunity. Sigh…

#23

Having said that: if the market’s there, Excelsior USA have every reason to produce a cross-compiler.

There is no reason why even today a PS2 game could not actually be coded in Java if Excelsior produced a compiler for it and someone wrapped the PS2’s functions with a JNI interface.

My experiences of Jet are that it has a particularly good memory overhead compared to the standard JVM and performance at least the equal of C++. It is, truly, the best of both worlds. You get the rapid development and test cycle of Java and then you get the other advantages of C++ when you cross compile it for the console. (You listening dleskov :wink: ?)

Cas :slight_smile:

#24

In fact Id think the market for a Java to PS2 native compiler could potentially be larger then that on Win32.

Your all already aware that I have my personal questions and issues with pre-compilation on Win32, but on a game console almost all of them go away.’

I am concerned about memory costs on larger game though. For CT it may well be a win because you decrease some of the over-head. On Shawn’s Java3D based games he found that compilation almost doubled his in-memory size…

#25

[quote]would this “C++ plus a script language” be portable to consoles, too, in an easy way?
[/quote]
I think it would help. For example the unreal engine uses a scripting language using their own VM (they call the Unreal Virtual Machine) which executes platform independent byte code. These bytecode files are compiled sources of UnrealScript, an OO scripting language with strong similarities to java. So they’re basically class files for UnrealScript. UnrealScript is not fast though (C++ is around 20 times faster last time I checked), but that’s not always important for what it’s usually used for. Besides they have something very much like JNI so you can write UnrealScript classes with native implementations written in C++.
They also have abstracted away the low level rendering layer so it works with 3DFX, Direct3D and (though not as good) with openGL and they had a software renderer too (I think that’s gone now though).
And Unreal Tournament is available on Win32, Mac, PS2 (I think XBox too, but I’m not sure) which might make it an option too maybe? I don’t know how expensive the license is though, but you can already download a UT demo and UnrealEdit (amazing development environment for games!) and play with it to see if its usable for you. I’ve done some hobby developing on it and I really like it. Another plus is that the engine is around for quite a while so it has lots of knowledge and tools available on the internet everywhere.
You might want to include it in your case study comparing C++ development, java development etc.

Erik

#26

[quote]In fact Id think the market for a Java to PS2 native compiler could potentially be larger then that on Win32.

Your all already aware that I have my personal questions and issues with pre-compilation on Win32, but on a game console almost all of them go away.’
[/quote]
I’m surprised hearing that coming from you :o :wink: but I fully agree.

#27

I can see where Jeff is coming from.

On Win32 you have many different processors in use, the dynamic compiler can optimize appropriately for what it is running on. PC’s have more RAM. They already have mature VMs.

On the consoles you have a known processor with known amount of RAM. There is less space available for things like HotSpot which need the JIT’d version and the original bytecode to stick around. Plus you save all the space that the JIT compiler itself would take.

For exclusive titles being compiled for one platform is an advantage because it will be harder to steal the title and have it run elsewhere… the opposite goal of run anywhere applies for an exclusive title.

I actually don’t think specific processor optimizations would be that helpful… assuming a game runs well on the minimum spec it is likely that the same machine code will run as well or better on a newer faster processor… though that isn’t always the case.

#28

I keep thinking in all this - where’s that Majc thing, or Jazelle, or Transmeta? A tiny bit of hardware assistance and the majority of issues are gone. Just like OpenGL support.

Cas :slight_smile:

#29

Compiling the Java source code to PS2 (Gamecube? Xbox?) sounds well. This would solve the porting issue of the game logic, probably.

Still two big “buts”:

  1. If I understand you correctly, there’s no such compiler currently. So, in case you visit publishers with a graphical/draft demo of your game, you can’t seriously answer their request how simple they could port the game to consoles.
    Even if your game’s scheduled release date was Q4/2005: saying that “maybe then a Java to PS2 compiler would be ready” wouldn’t sound well to the publisher, would it?

  2. What to do with 3d, IO, sound? Jeff pointed to this earlier in this thread. Say you use an OpenGL based 3d Java engine like Xith3d: how could this ever run on a console?
    Or is there some Java native binding for a PC+console 3d engine like Renderware?

#30

[quote] 1) If I understand you correctly, there’s no such compiler currently.
[/quote]
From what I’ve heard, any console development is likely to require some console-specific code (which is why many game firms require knowledge of assembly programming when hiring console programmers).

For Java, that might mean to hack GCJ to compile for the PS2. How much work that would require hasn’t been conclusively established in this thread yet. Jeff was sceptical of GCJ having a portable runtime, but the Kaffe VM lists a port for the PS2 (with Linux kit) on its homepage so I don’t know how much trouble that really means.

I would suggest you check with the GCJ folks before completely dismissing the option, maybe someone has already done it (maybe the Kaffe VM would be satisfy your needs?).

[quote]Say you use an OpenGL based 3d Java engine like Xith3d
[/quote]
Is Xith3D really OpenGL based? I was under the impression that Xith3D was written in a way that would assist supporting different rendering APIs. You will probably have to write the Java bindings to the PS2s rendering API yourself though.

#31

Unless consoles use very different rendering philosophy - and as far as I know, they do. Please note that most of Appearance attributes are 1-1 copies of opengl states. While it might be possible to emulate it under widly different architecture, I doubt it would be fast or complete enough to be acceptable.

Please note that I have no idea about HOW exactly PS2/etc differ from opengl/DirectX. Maybe it is still same capabilities, just under different names - but given lack of opengl ports for consoles, I doubt it.

#32

Well the xBox is based on a GF3, and obviously runs DX so its probably pretty similar. There was rumours of an OpenGL driver/library being produced for use with Doom3, but I havn’t seen it confirmed.

The GameCube uses an ATi chip, from what I’ve heard its pretty close to OpenGL for its API, deliberatly to make things easier for programmers to use something they are already familiar with. The most major change is probably the memory, not only is it smaller than a standard PC its got a unified main/graphics memory, and some separate, slower sound memory.

PS2 is a totally different beast from what I gather, a whopping 2mb of graphics ram, no T&L built in, or a depth buffer, and some weird vector co-processor that sits somewhere before where you’d expect the T&L pipe to start that doesn’t have any equivilent in PC architecture.

#33

Lo all,
Hope you all had a good Xmas/new year :slight_smile:

[quote]PS2 is a totally different beast from what I gather, a whopping 2mb of graphics ram, no T&L built in, or a depth buffer, and some weird vector co-processor that sits somewhere before where you’d expect the T&L pipe to start that doesn’t have any equivilent in PC architecture.
[/quote]
The vector processor (VU1) is the TnL part. Its sits just before the rasteriser, exactly where you’d expect it to be :slight_smile: However, you have to write the microcode for the TnL yourself, and (here’s the real nasty part) you have to do the clipping yourself too. However - you can generate geometry in the VU - which no other console can do.

The PS2 is very flexible, pretty fast, has phenomenal fill rate (2 giga pixels WITH alpha blending turned on! easily 4x that of the xBox). You can upload textures in the background, and you can build textures in VRAM dynamically without slowing rendering. We used this to get up to 7:1 texture compression, and this alleviates the small amount of VRAM you do get.

Its certainly very hairy to get going well, and none of these functions are provided out of the box - you have to code them all (you’re talking a years work or more just for this) It also has 16/24/ or 32 bit depth buffer (I always used 24, as you can then use the upper 8 bits for stencil buffering or depth-of-field effects). With careful use, you can also get 16+ pass multi-texturing, including DOT3 lighting!

However - Gamecube can as much, its CPU is much faster (PS2 CPU sucks a bit), and the graphics API is simplicity itself. By far the easiest to write for.

xBox - well, its a PC in a box from a couple of years ago. Fill rate is a big issue when alpha blending, and you have to use crazy nVidia stripping that bloats your strips with 30% degenerates.

Anyway, back to the main topic:
I would advise them to use C++, it is highly unlikely that Java will port easily to consoles - ever, and the main issue with porting from Java is dealing with the memory leaks (which really hurt on a console with no virtual memory).

It is possible to have a cross platform engine for any aspect of the game - Audio, Video, IO, its just a matter of clean API design. However, you can easily end up coding for the lowest common denominator which benefits noone (unless you don’t use any fancy effects anyway)

If you want to actually make money on consoles - PS2 is the one to go for, 4x the installed user base worldwide makes a BIG difference.

  • Dom
#34

Although latest reports are that gamecube is catching up on Xbox, interestingly enough…

#35

I’m not surprised seeing as you can get them for half the price!

Cas :slight_smile:

#36

When the game’s planed release date is quarter 3 or 4 in 2005: then the next console generation will be (nearly) ready.
No need to waste your time on a satiated PS2/GC/… market then.

Will the PS3 have a JVM or be able to run one from “CD” (medium) ?
(There’s been some talk about this here in the forum, but nothing concrete. No surprise beause the PS3 hasn’t been announced officially yet).

Will there be a Jet or GCJ version ready by of 2005, in order to compile your Java game or Java parts of the game to a PS3?

Such information could well influence the technical design decision you’ve to do today… :slight_smile:

#37

[quote]Will the PS3 have a JVM or be able to run one from “CD” (medium) ?
(There’s been some talk about this here in the forum, but nothing concrete. No surprise beause the PS3 hasn’t been announced officially yet).
[/quote]
Unfortunately there is no announce-able news in this space yet.
As soon as there is we WILL post here.

Gotta ask the guys who does those things :slight_smile: I think a JET guy posts here on and off. (We fight regularly about the value of pre-compilers in the PC space, he and I :slight_smile: )

Yep, wouls be nice. Ofcourse so would PS3 specs… ;D

#38

Something just caught my eye in crystalsquid’s post there…

what memory leaks exactly? I’ve never had a memory leak, ever, in Java.

Cas :slight_smile:

#39

Memory leak is a broad term - broader than just loosing last reference to piece of memory in C so you cannot free it later. I once had memory leak in java server code - I had to remember number of past messages which came from external machine. On certain event (change of production settings, which happened every few hours) I should clear the cache with old messages - but made a mistake in code and used wrong id for clearing it. This is clearly a memory leak - cache was holding ALL references to this particular type of message forever, which of course meant that after few weeks of work it could accumulate. Fortunately we had -Xmx set to 8MB in our test environment, so it crashed after one day :slight_smile:

So I think it is perfectly possible to have memory leak in java. But I doubt it is the memory leak crystalsquid was referring to - I suppose he just meant fact that java requires more memory that is actually used, to allow gc a bit of free space to work/copy/etc.

#40

I think Swing/AWT have had their share of keeping references to objects which had no reason to continue to exist.