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.

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.

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.

The vector processor (VU1) is the TnL part. Its sits just before the rasteriser, exactly where you'd expect it to be 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.

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... :)

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).

Unfortunately there is no announce-able news in this space yet.As soon as there is we WILL post here.

Quote

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?

Gotta ask the guys who does those things :) 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 :) )

Quote

Such information could well influence the technical design decision you've to do today... :)

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

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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

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

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.

When I mentioned memory leaks I was referring to the leaks you get in the C version after porting the Java version - because as you say Java cleans up for you. Lots of places where the object just goes out of scope (fine in Java) but in C++ thats a leak.Sorry if I wasn't clear

btw: for releasing a game for PS3 launch - don't bother. We rushed to get a game out for (near) PS2 launch, and tbh, even though we did sell a fair amount (proportionally), it paled into insignificance w.r.t. a PS1 game at the time. You would do better writing a PS2 game as the PS3 will probably be backwards compatible anyway, and there will be some 70+ million PS2s out there. Remember also that EA, Square, Sony, etc. will all have products ready to ship at launch - you will be fighting for a slice of a very small pie. Big pies good

btw: for releasing a game for PS3 launch - don't bother. We rushed to get a game out for (near) PS2 launch, and tbh, even though we did sell a fair amount (proportionally), it paled into insignificance w.r.t. a PS1 game at the time. You would do better writing a PS2 game as the PS3 will probably be backwards compatible anyway, and there will be some 70+ million PS2s out there. Remember also that EA, Square, Sony, etc. will all have products ready to ship at launch - you will be fighting for a slice of a very small pie. Big pies good :)

That sounds well.

I'm currently observing some friends' game project which will need good CPUs (2 GHz and higher) to handle the AI, real time (3d) animation, and so on.A PS2 or any other console isn't powerful enough to handle this. The team says when a publisher asks for a console version they'll name "next generation", ie PS3.

Still, if for sure the PS3 won't have Java, I can't even suggest to the crew to use Java as a Scripting Engine. ;-)

So I CAN tell you that it isn't for sure it WON'T have Java. Just that there is nothing announceable yet about whether it WILL have Java.

Understand the difference?

If all you are doing with it is scripting then you might be able to get away with a purely interpreted VM. I believe there are some open source interpreted VMs that are quite portable.

Otherwise we do know of one company currently that ported the VM to a console themselves in order to release a game. Thats a lot of work, particularly if the target console is very different from a desktop system like a PC BUT if a company did that its likely terms coudl be worked out with Sun to ship it as part of their app.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

If all you are doing with it is scripting then you might be able to get away with a purely interpreted VM.

I see. Of course I'd like to use more Java components.

In another thread there's some mention on sheets which show the productivity improvement of game crews using Java compared to some ancient languages. Any chance your trainee could scan them for us forum guys here? :-)

Quote

Otherwise we do know of one company currently that ported the VM to a console themselves in order to release a game. Thats a lot of work, particularly if the target console is very different from a desktop system like a PC BUT if a company did that its likely terms coudl be worked out with Sun to ship it as part of their app.

OK. My observed project focuses clearly on PC. It would be fine however to give a vision to a potential publisher's question for a (PS3) console option.

+In another thread there's some mention on sheets which show the productivity improvement of game crews using Java compared to some ancient languages. Any chance your trainee could scan them for us forum guys here? :-).

Yes sorry, icam VERY remiss on this. I can only beg over-work. Im working on our big thing for GDC this year (a bombshell I think), plus finishing the networking chapter for Shawn's book, and dealing with soem life issues.

As soon as I can remember to actually take the sheet with me over to Kinko's at the end of a day I'll get it scanned to PDF and up, I swear.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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 ?)

Well, we could of course make a cross-compiler, but we would need a lot of information and technical support from the platform vendor. An OEM agreement with them would be even better. But these are impossible to achieve via front door, because we are a very small company compared to Sony.

Does anyone here has good connections at Sony (or Nintendo)? Can you put them in touch with us?

I recall I have heard some time ago Sony worked with Sun on someting called Java Game Profile...

It's not that much faster to develop in... that's really a little overhyped Where it comes into its own is in the supporting technologies that come bundled with it and the other bells and whistles like security.

All the complexity from games writing these days (on the client) comes down to telling graphics cards what to do, and if you have to completely rewrite that aspect of it to work across platforms anyway... maybe there's not such a great saving after all.

I'll eat my words when you produce a native compiler for PS2 so I can run Alien Flux on it

It's not that much faster to develop in... that's really a little overhyped

Not in my case Cas. Im dead serious when I say I produce final bug-free code in what I estimate to be 1/8 the time in Java. If your around for GDC come see the server system I'm just finishing and that I wrote top to bottom single-handed in about 6 months. Last I heard game teams in C were spending many man-years on servers that do a lot less.

Ofcourse your results may be different then mine. every programmer has their own best style of working and performance trade-offs.

I also think it really depends on the compelxity of your task. yes, I agree if all you are doing is pushing pixels around then the savings is porbably somewhat less. Most modern games however DON'T just push pixels around. They are very logically complex peices of software and its here where Java shines in productivity.

Yes I know I still need to get the sheet from the GDC 2 years ago scanned in. It has some numbers that tend to show my experience isnt outlying. Hopefulyl I'll geta breath before GDC to do that.....

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

I fully agree it's at least 10x faster to develop server code, but client code is usually about wrestling with OpenGL and getting your head round horrible mathematics for me Which takes as long in any language for my tired old brain.

I fully agree it's at least 10x faster to develop server code, but client code is usually about wrestling with OpenGL and getting your head round horrible mathematics for me :) Which takes as long in any language for my tired old brain.

This is valid just for small games like Alienflux or my hobby projects, Cas, just for them.For full price games (=client), Jeff's absolutely right. Your efficiency gain with Java is enormously, as with most complex applications.

Probably worth looking again at AF and redefining your definition of "small" ;D

What I tried to say has been AF's small compared to a complex fullprice game like, for example, Ground Control II. It needs 20 (or more) people to work full-time for about two or three years, just to release a very first version with bugs and no perfect game tuning.

For a small team (one developer plus one graphic artist you've been?) AF is of course a big project.

It's difficult to make a nice game (which AF definitely is) no matter of its size. It's an art in both cases.

Quote

I admit it would have taken a while longer in C++

Naturally.

Quote

but I'm also fairly certain there are plenty C++ programmers out there who are far more competent at C++ than I am at Java!

This is a new discussion then and has nothing to do with the "Java is more efficient to program in than C++" ? ;-)

Ah, but I think you'll find it doesn't take anywhere near that manpower. You'll find typically no more than 3-4 fulltime programmers on a game, and one of those will probably be dedicated to tooling. There are obviously exceptions but that's the norm.

Ah, but I think you'll find it doesn't take anywhere near that manpower.

The number's been for the entire game, not "just" the programming, yes.

Quote

You'll find typically no more than 3-4 fulltime programmers on a game, and one of those will probably be dedicated to tooling.

Let's say four fulltime programmers plus additional programmers for tools, scripting, etc. They can fully concentrate on programming, in contrast to you having to handle the design, research, project management, testing, sell management, etc.So they're at minimum 4+ times as many as you've been and the "Java efficiency factor" will be huge. ;-)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org