Down with J3D, Software rendering rules!

Engines, Libraries and Tools Java 3D
#21

if gameplay is good enough graphics hardly matter, they are not essential to a good game

books don’t look good, some of them even smell funky, but because they lack surround sound and thx enhanced video and two-hours of explosions (don’t get me wrong i like it when stuff blows up) they offer something that movies can’t. They utilize the imagination and stimulate the mind better than a movie could hope to achieve (their are some movies but on average)

This isn’t a direct comparsion to games with and without quality graphics, but merely an insight to things of greatness that are possible in things that may be culturally and technologically inferior to others. What appears to be a weakness can turn out to be the greatest strength.

#22

Um, I have to say, I’d rather have both. Nice graphics and great game play.

I assume you’re talking about flat shaded 3d software rendering as the alternative (a la your rather impressive space pirates game). As much as I respect what you’re saying, having the ability to display detailed effects can add to the intricacy and subtleness of the gameplay. Overall, this can add to gameplay in a massive way.

There is one overwhelming factor why j3d is worth while tho, its far far far easier for the hobbiest to get into than writing a software rendered off the cuff.

Kev

#23

I still think that 1.1. has its place, too. There are bazillions of machines out there that can only do 1.1. and it’s not always possible to force people to upgrade. Either they don’t want to for whatever reasons, they are not allowed to or they don’t know what the heck you are talking about. At work, i’m limited (like the whole company) to Java 1.3 running under NT4…this means no LWJGL (as long as it isn’t natively compiled like CAS did it with Alien Flux) and caused by limited user permissions, i can’t install anything on my work-machine. I’m happy if someone supports software rendering in games (despite that software rendering includes software rasterizing for me…does your engine do this or do you simply use AWT’s stuff to draw the polys?).
With jPCT (http://www.jpct.net) i tried to support both in the best possible way, i.e. you’ll get 1.1 compatible software rendering (with some enhancements for 1.3 and higher) and support for LWJGL assisted hardware acceralation if you have 1.4/LWJGL installed. The drawback is, that you can’t do some things that would be possible with hardware alone because you always have to take care of the software path (but that’s true vice versa to a degree). But then again, how many Java games are using these super-duper-features of modern hardware? Making at least a lowest common dominator accessible in a convient and easy way is more worth than offering all the latest and greatest that will never see the light of day for various reasons IMHO.
Oh, and btw: 65fps on a P4@3.2Ghz using the MSJVM (at a processor load of aorund 2%) and 30fps using the 1.4 plugin (at a load of 50%)…something is wrong either with the Sun JVM or your engine here. jPCT performs almost the same on MS’ JVM and Sun’s.

#24

i use the awt for all my draws in this game anyways

that might be the cause for jvm slow speed or perhaps the threads i choose to use, either way jvm is messed with this game msvm is the only way to go

#25

[quote] msvm is the only way to go
[/quote]
Yes, it’s only been dead for, what? Three years now?

#26

On the msvm I get 33fps instead of 30fps and when I want to close the window I have to close all browser windows instead of only the one with the applet.

#27

LWJGL is pretty damn fast. I draw 160 quads all with a blended texture to them and get ~70 fps in 1024 768 32 and 35 in 1600 1200 32 :slight_smile:
I use display lists and now working on quad trees :slight_smile:

#28

[quote]LWJGL is pretty damn fast. I draw 160 quads all with a blended texture to them and get ~70 fps in 1024 768 32 and 35 in 1600 1200 32 :slight_smile:
I use display lists and now working on quad trees :slight_smile:
[/quote]
Well, no offense but 70fps for 160 textured quads is not damn fast, it’s rather damn slow. Maybe you try it with VSync disabled. 70 and 35fps sound very much like a VSync limit to me.

#29

EgonOlsen alluded to this, but I think it bears repeating - different technologies/approaches are best for different games. For example, if you’re writing for hardcore twitch gamers, you’d better be taking advantage of as many video card tricks as you can. If you’re writing a game in one of the many genres that doesn’t carry the expectation of flashy graphics, awt is all you need. It’s an important design concept, rarelt is there a generically best choice - what’s best depends on the context.

On another note, how good a game looks probably depends far more on how good your artist is than the technology you use. A 2D game with good sprites/backgrounds/menus will look far more attractive than a 3D game with three repeating textures.

#30

For the software-rendering aficionados out there –

http://www.komplex.org/java.html

These guys were the best a few years back, but their demos were written for 1.1, and barely run on todays VMs… :’(

For Java 2 users, check out these demos:

http://www.sumea.com/www/goodies.html

#31

…then have a look at the 3D demos (the apartment demo for example), fire up the IE with a MSVM (yes, these demos do run with 1.1) and experience twice the performance (at least…75 compared to 32 on my machine). Like the applet game that started this discussion, the sumea 3D engine is a nice example of a software renderer that cripples under 1.4…what the hell are they doing?

#32

[quote]…then have a look at the 3D demos (the apartment demo for example), fire up the IE with a MSVM (yes, these demos do run with 1.1) and experience twice the performance
[/quote]
I believe this symptom was analyzed in an earlier thread (was it for erikd’s emulator?). Then the problem was that the programmer had optimized his code for the MSVM by inlining just about everything (since the MSVM can’t perform the same kind of inlining as Hotspot), ending up with 1500+ line methods. Since Hotspot is engineered to support object-oriented design with many methods that can be individually profiled, compiled and inlined, the ugly MSVM-optimized version of the code did not perform very well on Sun’s JVM.

The programmer refactored his code and got a much more readable program that performed a lot better with Sun’s VM. Maybe the Sumea engine also consists of similar overly-large methods.

#33

[quote]Well, no offense but 70fps for 160 textured quads is not damn fast, it’s rather damn slow. Maybe you try it with VSync disabled. 70 and 35fps sound very much like a VSync limit to me.
[/quote]
First of all, Vsync yes :slight_smile: And the reason for those quads to slow down it all so much is because they are all high-res textures with alpha blending.

#34

[quote]I believe this symptom was analyzed in an earlier thread (was it for erikd’s emulator?).
[/quote]
Ssshht! don’t mention that to everyone ;D

There’s some things that I learned during that excercise:

  • Don’t assume anything or make premature conclusions
  • Don’t write particulary for one VM by practicing bad programming habits (like manual inlining).

Maybe the 3d demo’s suffer from the same problem, but since we haven’t seen the source, we don’t know so we can’t tell.
The end of my excercise had the emulator running fine on the Sun 1.4 VM with better code, but still generally slower than on the MS VM (ranging from significantly slower till a little bit faster, depending on the emulation driver being used).
For these kind of things, MS VM seems generally faster than Sun still. I can’t explain why, but most applets simply prove that. This does not mean the Sun VM is generally slower than the MS VM, but for these kind of applet it seems true.

Read the discussion here, but don’t tell anyone I started that topic: :wink:
http://www.java-gaming.org/discus/messages/27/1531.html?1029399057
http://www.java-gaming.org/discus/messages/27/1546.html?1029399057

As a side note, I’m still waiting for a 1.4 VM for windows coming from IBM … (for games it seems faster than Sun VM and faster than MS VM. My emulator runs best on IBM 1.3 JRE).

[quote]For the software-rendering aficionados out there –

http://www.komplex.org/java.html

These guys were the best a few years back, but their demos were written for 1.1, and barely run on todays VMs…

For Java 2 users, check out these demos:

http://www.sumea.com/www/goodies.html
[/quote]
I tested some applets from both links on Sun 1.4.1_01 and MS VM and I could hardly see the difference to be honest, although the MS VM seems a little bit more smooth. I also did some profiling on the Sun JVM which shows that it doesn’t suffer from the problem I had in the past (The Sun JVM not compiling because of manual inlining).

Erik

#35

[quote]I tested some applets from both links on Sun 1.4.1_01 and MS VM and I could hardly see the difference to be honest, although the MS VM seems a little bit more smooth.
[/quote]
Try the apartment applet (it has a framecounter)…like i mentioned above: 2 times faster on MSVM on my machine.

Link: http://www.sumea.com/www/apartment/index.html

#36

On my work-PC (P3-1Ghz running win2k) I got the following numbers:
MS VM : 9-18fps
Sun 1.4.1_01 : 6-15fps

On my home PC (Athlon XP 2200+ running winXP) running 1.4.1_01 it ran like a pig. Absolutely terrible. Varying from 1 - 8 fps on such a machine is just embarrasing. I couldn’t switch back to the MS VM, the option is not there somehow so I don’t know if it’s any good on that one. ???

MS is faster indeed (although not nearly twice as fast on my work machine).
Although I appreciate the effort of a software renderer, it’s still so terribly slow on any VM that I can’t think of any use for it.

#37

[quote]Although I appreciate the effort of a software renderer, it’s still so terribly slow on any VM that I can’t think of any use for it.
[/quote]
Trying to discuss the uselessness of software rendering these days is like trying to convince cas that threads are a good thing… ;D …JK…
jPCT’s software renderer can render a simple indoor scene with some models and animations at around 25fps in 640*480 on an Athlon XP 2100+…i wouldn’t call this terrible slow and it is for sure fast enough for a lot of applications. Can’t speak for sumea though… :wink:

Edit: Your Athlon’s results for the sumea demo sound strange. I had it running on the Athlon 2100 mentioned above some month ago and while it wasn’t blazing fast on SUN’s VM, it was acceptable.

#38

After rebooting, it ran better (20-32fps). :-/

[quote]around 25fps in 640*480 on an Athlon XP 2100+…i wouldn’t call this terrible slow and it is for sure fast enough for a lot of applications
[/quote]
Okay that’s even pretty damn fast… for a java software renderer. :slight_smile:

I suppose software renderers do have its use, only not for me.

#39

i got 20-45 fps on AMD1800 256 and g4ti4200

thats one of the nicest software rendered pieces of java i’ve ever seen (that runs over 5fps)

they even made the sinks reflective!