Java 3D-engine

[carpediem]

Has anyone heard anything about this engine? It supposed to have Real Time shadows, self shadowing, etc. I guess it's possible to get decent performance from a java engine too, or?

http://www.agency9.se/products/agentfx/

Playable "demo" here:
http://www.megacorpsonline.com/downloads/

 

[Scali]

Firstly, Java is not all that much slower than C/C++ in most cases, as long as you write decent code.
Secondly, if you use 3d acceleration, the most performance-critical part is no longer in Java, but in hardware.
So yes, Java can work fine for games. Not cutting-edge games perhaps, but if you simplify them slightly, there should be no problem.

In this case it doesn't work though, it seems... I can't get the game to start, even though I have JDK 1.4.2_02 installed, and Java3D 1.3.1 for OpenGL.

 

[ERP]

It's becoming possible to move more and more of games to interpretted languages.

I personally wouldn't write my main rendering loop in an interpretted language just yet, but on a PC at least the majority of game logic and AI can certainly be done there.

Having said that I wrote a small 3D modelling package (more of a toy to try some things) in Java with OpenGL bindings and there were no significant performance issues.

As was mentioned above with a few exceptions (most notably array references) Java can run at comparable speeds to C++.

 

[Scali]

Well, as I mentioned before, elsewhere on this board, I wrote a Java software renderer last year: http://www.pouet.net/prod.php?which=10808
I could even get away with realtime metaballls at quite decent resolution, and bilinear texturefiltering, even with EMBM.
Even with that engine, you can probably make a reasonable game today... Let alone if you use 3d acceleration.

 

[Richard]

That Xpand rally game uses JAVA (though I'm not entirely sure if it's used for the renderer). And it's only going to get more pervasive. With WinFX coming with Longhorn's .net I'd expect amateur programmers to dable with it and create their own versions of tetris, pac man, whatever, all using an interpreted language and without even touching OGL/D3D.

 

[Scali]

That Xpand rally game uses JAVA (though I'm not entirely sure if it's used for the renderer). And it's only going to get more pervasive. With WinFX coming with Longhorn's .net I'd expect amateur programmers to dable with it and create their own versions of tetris, pac man, whatever, all using an interpreted language and without even touching OGL/D3D.

Neither Java nor .NET are interpreted though. They are obviously JIT-compiled. Which is why they are not that much slower than regular compiled languages. Interpreters are probably a factor 10 slower.

 

[Farid]

IIRC, Vampire The Masquerade, Chrome used Java for their engines.

 

[Richard]

Neither Java nor .NET are interpreted though. They are obviously JIT-compiled. Which is why they are not that much slower than regular compiled languages. Interpreters are probably a factor 10 slower.

??

Java programs are run on -- interpreted by -- another program called the Java Virtual Machine (Java VM). Rather than running directly on the native operating system, the program is interpreted by the Java VM for the native operating system.

 

[ERP]

Neither Java nor .NET are interpreted though. They are obviously JIT-compiled. Which is why they are not that much slower than regular compiled languages. Interpreters are probably a factor 10 slower.

??

Java programs are run on -- interpreted by -- another program called the Java Virtual Machine (Java VM). Rather than running directly on the native operating system, the program is interpreted by the Java VM for the native operating system.

What the later Java runtimes do is compile the byte code into native assembler as it's running. This happens just before the code is about to be executed (or Just In Time JIT). Theoretically this allows for some rather interesting optimisations, a JIT compiler can theoretically unroll loops optimally for any cache size because it can measure the performance of the compiled code and try a different strategy based on the results.

The main problems with languages like C# or Java is they look a lot like C++, but they behave very differently, a great C++ programmer has a pretty good chance of producing very poorly performing Java or C# code. As a result they tend to get an undeservedly bad rap for performance.

 

[Scali]

What the later Java runtimes do is compile the byte code into native assembler as it's running. This happens just before the code is about to be executed (or Just In Time JIT). Theoretically this allows for some rather interesting optimisations, a JIT compiler can theoretically unroll loops optimally for any cache size because it can measure the performance of the compiled code and try a different strategy based on the results.

The main problems with languages like C# or Java is they look a lot like C++, but they behave very differently, a great C++ programmer has a pretty good chance of producing very poorly performing Java or C# code. As a result they tend to get an undeservedly bad rap for performance.

Have you by any chance developed Java/.NET for an extended period of time aswell? I have, and your words are exactly my thoughts.
It is how I came to these insights that they require a different approach to optimization, and since most people don't know this, and only know how to write poor code, and then the fact that many starting programmers take up Java and produce poor code (the VB-syndrome), Java has a much worse reputation than it deserves.

It still pisses me off today everytime I hear it, even though I haven't developed Java in well over a year. Especially the ignorance about JIT-compilers, and people shouting 'interpreter' and associating it with bad slow emulators from the days of old.

 

[ERP]

I have a soft spot for languages in general. It's one of the things my degree concentrated on.

I spent a lot of time messing around with Java back in the 1.1 days, and I've been using C# for quick tools work more recently. Both are better designed languages than C++ and garbage collection is a beautiful thing if it's done right.

I wouldn't use either for most of the runtime stuff I do at work, but for tools I can do in an hour in C# what would take me a day in C++ and MFC.

I occasional do educational presentations at work on how to structure code for performance, and I was noting with someone in my group a few days ago that 90% of what I tell people is the right thing to do in C++, is absolutly the wrong thing to do in Java and C#.

 

[Scali]

I have a soft spot for writing fast code.
I was introduced to Java at uni, and I started trying some simple 2d graphics effects, to see what was possible. Then I met another guy at uni who was also doing graphics stuff in Java, and together we also started to do 3d stuff, and we studied the JVM internals and tried to figure out how to get the most from Java.
Eventually he came up with a Quake level renderer, and even added bilinear filtering to it. It wasn't all that fast yet, and the engine was rather limited, but the idea that it was almost possible was quite intriguing to me.
A few years later, with PCs of 2 GHz and more, I decided to pick it up again, and do a modern DX8-style renderer, complete with hot-pluggable vertex/pixelshader objects, and ofcourse bilinear filter, and some post-processing, and this time I could actually get away with it.
To me, Croissant 9 is pretty much the completion of my goal of doing high-end realtime stuff in Java.

 

[DemoCoder]

Here's two messages I wrote on Java performance awhile ago, especially the modern GC performance (concurrent and parallel generational collectors) and the possibility of escape analysis.

http://www.beyond3d.com/forum/viewtopic.php?p=60678#60678

http://www.beyond3d.com/forum/viewtopic.php?p=247683#247683

I think OCaml demonstrates that a GC based languaged that can be interpreted bytecode or compiled (your choice) can be blindingly fast. The main problem with Java has been the slow API libraries (Swing), lack of pre-compiled API libraries (fixed in 1.5) that caused slow "startup", and no "value" objects (fixed in C#)

Things have evolved alot since 1.0/1.1 days. I wrote an app the other day using the new 1.5 Tiger features (generics, enums, collection iterators) and it was much better. The new concurrency utilities are awesome, and now multithreaded programming is even easier to get right, more powerful, and faster (a factor of 10 times faster than the 'synchronized' keyword in some instances)

My only pet peeve is the way Generics were implemented without VM support. Unlike the C#.NET implementation, you can't instantiate templates on primitive types.

 

[Richard]

It still pisses me off today everytime I hear it, even though I haven't developed Java in well over a year. Especially the ignorance about JIT-compilers, and people shouting 'interpreter' and associating it with bad slow emulators from the days of old.

FYI, I know about JIT and dynamic recompilation, what you apparently forgot was the context I wrote my post about: amateur programmers dabling with WinFX, using managed/interpreted/high-level languages. I was talking about the massification of programming, specifically, 3D programming.

I don't see how you could have read my post and mistaken me as someone who dislikes JAVA (or .net for that matter).

 

[DemoCoder]

I don't think the switch to GC'ed pointerless languages with a higher level API will neccessarily enable the masses to write 3D game engines. You still need to understand a fair amount of linear algebra and how the hardware works if you want to truly do anything interesting besides rendering cubes and terrains.

In fact, I'd say that more important that merely understanding the math, is understanding data structures and algorithms involved in maintaining the world geometry and physics, and how to efficiently query and update these. Otherwise, you can't "scale" anything up to game size and are left with mere demos.

Moving from C++ to C#/Java merely alleviates the boredom of having to deal with mainly irritating issues in a language like C++, e.g. memory leaks, null pointer derefs, memory allocation strategy. However, anyone who has learned data structures and algorithms probably had to learn atleast Pascal, C or C++ anyway, so it is not like a novice Visual Basic programmer can miracously use Managed DX to write Doom3 if he has never had exposure to lower level languages.

An experienced C++ programmer *could* conceivably write D3 or UE3 in C# (or Managed C++), or in Java. I don't think an experienced VB programmer who did nothing but forms processing and databases could neccessarily make the transition as easily.

(I'm not trying to be snobbish here,I love high level languages, but I believe you also have to learn the low level stuff too so that you can understand what's happening in the high end system "behind your back")

 

[Scali]

It still pisses me off today everytime I hear it, even though I haven't developed Java in well over a year. Especially the ignorance about JIT-compilers, and people shouting 'interpreter' and associating it with bad slow emulators from the days of old.

FYI, I know about JIT and dynamic recompilation, what you apparently forgot was the context I wrote my post about: amateur programmers dabling with WinFX, using managed/interpreted/high-level languages. I was talking about the massification of programming, specifically, 3D programming.

I don't see how you could have read my post and mistaken me as someone who dislikes JAVA (or .net for that matter).

I don't see how you could have read my post and mistaken it as being aimed at you personally (it wasn't, I was speakin in general).

Or well, perhaps I do... because in your first post, you specifically only state 'interpreted', not 'managed/interpreted/high-level', and in your second post, you actually try to defend the 'interpreted' part, after I tried to clear up that JIT-compilers are used instead of interpreters.

On another note:
Some nice info there, DemoCoder.
That stuff about custom allocation code is very true. In my 3d engine for example, I first had a naive matrix*vector method, which created a new object for every result. Obviously the garbage collector went crazy over that, when I ran high-poly meshes through the engine.
When I started optimizing the engine, I created a pool of vector objects for the result, and made an alternative matrix*vector method that reused the objects in that pool. And as you can see in the resulting demo, there are no visible gc-pauses at all anymore.

 

[Snyder]

The main problems with languages like C# or Java is they look a lot like C++, but they behave very differently, a great C++ programmer has a pretty good chance of producing very poorly performing Java or C# code. As a result they tend to get an undeservedly bad rap for performance.

Funny, I thought the same about Java for some time - until I noticed how crappy my code was... (But: Swing is still teh evil.)

 

[Richard]

DemoCoder: Agreed. But I wasn't talking about D3-level (or even Q1-level) engines. I mentioned Tetris and pac-man type 3d games. Real simple 3d apps that most amateur programmers now do using 2D, could be done in 3D when WinFX/longhorn arrives.

Using the same "winforms" programming background, coupled with a 3d backend already enabled by default (IIRC, even with SM 2.0 interface for special effects) should allow beginners to make a 3D rubik cube app quite easily. That's the discussion I was trying to start, anyway.

 

[psurge]

Does anyone here have any experience with Eiffel?

 

[K.I.L.E.R]

Swing under Java 5 uses Direct3D behind the scenes while under non Windows OSs it uses OpenGL.