I just tested the terrain demo (WinXP, JRE 1.4_01, GeForce2TI), but it crashed:

An unexpected exception has been detected in native code outside the VM.Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x0Function=[Unknown.]Library=(N/A)

NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions.

Current Java thread: at com.powersolve.opengl.GL.wglAllocateMemoryNV(Native Method) at com.powersolve.jglib.AGPMemory.reserve(AGPMemory.java:101) at com.powersolve.opengl.GLClient.run(GLClient.java:104) at demo.client.Demo.main(Demo.java:275)

Ooh, bugger, well I'm not entirely sure why it crashed it has to be said, coz it seems to work generally well on any Geforce based system, even horrid Win98.

...unless you've got AGP stuff turned off in your BIOS.

...or you're running a 16 bit desktop which tends to throw it, I didn't really attempt to code around all sorts of different configurations coz it was just a little hack I was working on to learn 3d graphics.

<fx: blows own trumpet>That terrain demo I did last year still doesn't seem to have been surpassed even by commercial engines yet - I looked at it again the other day and wondered how I ever managed to do it. It didn't really receive recognition as being Java because it didn't use Sun endorsed libraries. That doesn't make sense. Never mind.

Cas

But isn't that the one that uses a DLL, and so isn't actually just Java? I thought it looked really good, until I saw the DLL, at which point I begin to compare it with Nvidia's demos (or any good OpenGL stuff).

There's a big difference (whether or not there SHOULD be, and my own personal opinion aside) between "a pure java library that isn't endorsed by Sun" and "a JNI windows-only DLL that could in theory be compiled on other architectures that isn't endorsed by Sun".

It's pretty clear that to get decent speed out of a graphics pipeline you need to do some native work. You can't just write a software renderer and pump pixels onto a BufferedImage for display by the GUI without things crawling to a halt.

Java3D has a native part, but that's been written by a team of developers employed by Sun using Sun's money, time and hardware. So the real difference here is just the "endorsement" bit.

*Shrug* I guess everyone has their own opinion on an issue like that, and rightly so!

Much of Java is implemented using native code; although some of the standard library functions are pure Java, many aren't (and e.g. AWT by definition cannot be).

I am not making a point about native code; I am making a point about native code that ONLY runs on ONE java platform. If a java app runs anywhere that has a byte-code executor (BCE), then it's definitely java. If it runs anywhere that has a "standard"/"well-supported" BCE, then it seems we should call it java (because the days of "every platform has a BCE" are over. I actually remember once gettting hold of a DOS JVM whilst I was working in IBM. Nowadays, if every "major" platform is covered, that seems to be considered good enough, according to consensus opinion).

The problem here is that Sun doesn't appear to have a clear definition of how many platforms something has to run on to be "real" Java as opposed to "a C++/ASM program that happens to have used some bits of Java". Witness the fact that most java developers considered Microsoft's extended-Java as "not real java" although in an abstract sense it was arguably a perfectly valid form of java, with extra bits (ignoring for the time being the bits that weren't updated in line with "mainstream" java moving to 1.2 then 1.3 etc).

I suspect that this vagueness is largely because Sun doesn't wish anyone to start making loud noises about how they in particular (sun) should actively develop (and support) a JVM on every platform.

So, if the terrain demo came with 3 native binaries - one for Win, Unix, and Mac OS, I would personally call it a "java" demo. With only a win binary, it's a win32 application that only runs on windows. Seeing as that breaks one of the top 3 most fundamental aspects of java - WORM - I find myself convinced by the arguments of the apparent majority: it is a Windows demo.

Personally, I consider it a windows demo, with Java scripting controlling it. It's a hybrid. If it used Java3D, I'd call it a java demo (personally, but I suspect many people would still call it non-java, as explained below...).

W.r.t. Java3d, I suspect that at least part of why J3D still languishes as a freak that Sun leaves out in the cold (excuse the extreme statements; but J3D has been around for YEARS without getting made mainstream by Sun) is because of the "java trochotomy". I honestly cannot believe that Java2D is used in more cases that Java3D would be if it were part of the standard libraries - high-precision CAG etc (most of J2D) is used a lot less often in general client-GUI programming than 3D is (or would be, if it were easily available to developers).

What is Java? Java is... [the trichotomy:]...an assembly language (the bytecode) AND the associated virtual processor architecture...a programming language (the syntax)...a common set of libraries (java.*)

(playing devil's advocate:) Java3D can never be truly part of Java because to call it "java" would either mean modifying the byte code to allow for 3D-hardware interaction, or would mean that Java-defined-as-bytecode was no longer a valid definition. Witness that Sun has historically moved Java away from anything that is hardware-specific (AWT ceded in favour of Swing).

Shrug. Maybe I'm just pissed-off because 90% of my machines, running up-to-date JVM's, can't run a given program because they're unix, linux and Mac OS. I can even run almost all non-graphical java programs on an Acorn, without recompilation or additional bug fixes, so not being able to run something on mainstream platforms is a major annoyance, considering this is one of the advantages of java.

Witness the fact that most java developers considered Microsoft's extended-Java as "not real java" although in an abstract sense it was arguably a perfectly valid form of java, with extra bits

Well, it included instructions that aren't part of the Java Language and added new opcodes that aren't part of the Java Platform, therefore breaking platform independance. It also completely broke the license agreement MS had with Sun, but hey. I have to say I'm one who doesn't consider it "real Java" either. If they just added a com.microsoft.* package I suspect there'd be no problem. It was the "embrace and extend" policy that did them in.

Quote

So, if the terrain demo came with 3 native binaries - one for Win, Unix, and Mac OS, I would personally call it a "java" demo. With only a win binary, it's a win32 application that only runs on windows.

Ah, I get you now. Yeah, I guess the problem is that it wasn't developed as an application but as a technology demo. Once Cas decided there was reason to continue with his little OpenGL binding he called it LWJGL, packaged it up with audio, input and vecmath support, and the rest is rapidly becoming history.I guess this all adds to the suggestion that Cas needs to port it to LWJGL so it's up-to-date, maintainable, more widely available and more useful as a learning experience.

Re: Java3D and what Sun consider "standard" libraries, I think Sun really dropped the ball on this one. They've kept adding things to an already over-burdoned API. There are a number of APIs that should never have made it into core - what they needed was a proper profile system from year dot. There was an excellent article doing the rounds a while back that put forward an excellent case for moving to Java3 and fixing all the things that have gone wrong over the past few years. Alas, it's too late for that I fear!

So, if the terrain demo came with 3 native binaries - one for Win, Unix, and Mac OS, I would personally call it a "java" demo. With only a win binary, it's a win32 application that only runs on windows.

I disagree.You are only making things vague (you have to support 3 platforms instead of one to call it java?). For me, java doesn't have to be everything but native. Java is not only about platform independance.Maybe there are 'official rules' about what's java and what is not but really, I couldn't care less.One of java's niceness is that you can quite easily integrate with native stuff. That's exactly what the terrain tech demo shows. Also, 'a native dll scripted by java' is just crap as I believe the DLL is only the ogl binding.

Well, I look at it more as an observation that for me as a developer, the Terrain.zip is an excellent technology demo for what can be done with Java. As a user of an application, it's irrelevant that it's in Java if it will only ever execute on Windows. Users don't care about the language an app is written in.

I agree that a debate over "pure Java" is pointless though, as it's merely arguing over the definition for something.

Huh? I wasn't attempting to make any contentious statements, guys, just trying to offer a potential explanation of why cas's demo has had comparitively little wide recognition. Perhaps statements such as "playing devil's advocate" were not obvious enough for you?

erikd:"I disagree.You are only making things vague (you have to support 3 platforms instead of one to call it java?)."

That's what is happening RIGHT NOW with Java, though I'm sure Sun isn't exactly overjoyed at having to be the main suppliers of a Windows-JVM and a Linux-JVM, with all the associated support costs of keeping them up-to-date.

I'm not making any decisions here - I'm just describing the way the world is. Of course SOMEONE has to support 3 platforms for Java. The theory of a BCE was that once one BCE existed for a platform, everyone else had to do zero support for that platform; this is the point of bytecode. If you are going to bypass a JVM e.g. by using JNI, then the "free" support you were getting on the various hardware platforms vanishes, and you need to provide it yourself.

In theory, as soon as a JVM existed for each main platform, Sun never had to develop for other platforms, they could just keep improving the Solaris JVM. It hasn't quite worked out that way. I'm sure we all wish it HAD worked out as intended; perhaps if bytecode had been more extensible, we wouldn't be in this mess .

erikd:"For me, java doesn't have to be everything but native."

Fine; many disagree with you. Partly, I expect, because if you throw away the bytecode-definition of Java, all you are left with is a variant of C++, which loses so much (STL, for instance) that on the whole it's probably not an improvement. Bear in mind that Java is not even a fully OO language; without the bytecode, java is hugely weakened as a proposition.

erikd:"Java is not only about platform independance."

No-one said it is. But currently Java IS three things, and you cannot just arbitrarily decide to ignore any of the three - they are declared indivisible by Sun. You are attempting to re-define Java as being just 2/3 of what it actually is. Sun could solve this by defining the three concepts as three different names - perhaps "JavaCode, JavaLang, and JavaLib" - (this has been suggested before many times since the inception of Java).

erikd:"Also, 'a native dll scripted by java' is just crap as I believe the DLL is only the ogl binding."

OK, so to help me understand, please explain where all the pretty graphics are coming from...

Perhaps you don't understand what "scripted" means? It means that the java is controlling other code, in a different language to the other code. Where is all the "hard" work of drawing those graphics coming from? Is it java code? (my assumption was no - perhaps I am wrong) Is it OpenGL hardware? (my assumption was yes - in which case, the Java code is just scripting layered upon system-level code (i.e. a C++/ASM DLL that is actually doing system-level tasks, such as interfacing to hardware).

Similarly, like many programmers (I had thought all, until now - you clearly don't look at things the same way), I would never look at an OpenGL demo coded in C++ and go "Wow! C++ can do such cool stuff!" - because in that case C++ is the scripting language, and it is still an OpenGL demo that you're looking at.

I've certainly never met anyone in the games industry who didn't differentiate between C++ and OpenGL. I can almost guarantee that if you show the demo to a mainstream studio or publisher, they won't go "Oh wow, java really CAN do great stuff" - they'll go "that's just OpenGL...so what can Java do?".

Or, to put it yet ANOTHER way, I expect you could probably do that demo in Perl (I *know* you could do it in Python). This does not make Perl look good - it just shows that you can access other compiled libraries from within perl.

Well, I look at it more as an observation that for me as a developer, the Terrain.zip is an excellent technology demo for what can be done with Java.

But it doesn't DO anything with Java other than to delegate to OpenGL and hardware. To a developer, it indeed shows that "you can use OpenGL hardware from a java app, using JNI". But to a user, it's just-another-OpenGL-app - which says nothing new about Java.

Quote

As a user of an application, it's irrelevant that it's in Java if it will only ever execute on Windows. Users don't care about the language an app is written in.

I don't understand this; this is blatantly not true - and you have evidence in my post where I mentioned that I can run normal java apps on any of my machines, but I can't do that with this terrain demo. Your statement's only true if everything you ever want to run is available as a pre-compiled binary for your platform (and THAT is easier said than done; most developers cannot test and maintain their apps on multiple architectures, unless the effort-per-additional-arch is very low - to anyone who ever had to use NT for Alpha, there is the familiar story of "binaries available for intel-NT and alpha-NT, but the alpha version is 1 year behind and might not work"; many people point out that java is not *truly* write-once-run-anywhere - but those with long experience of the hellish days of cross-platform coding before java don't really care, because the platform-dependencies in java are so trivial compared with the sh*t we used to put up with).

If all a user ever uses is Windows, and everything they ever want to run is a windows app, then it may well seem to you that they don't care. But if Doom3 were released 6 months early on linux, you'd find they did care pretty quick (contrived example) - if it were written in java, they'd be able to play it. If not, they have to wait 6 months.

Quote

I agree that a debate over "pure Java" is pointless though, as it's merely arguing over the definition for something.

Who's debating? I'm not; I merely pointed out that:

1. it's poorly defined2. therefore, one man's "java demo" is another's "windows demo" - and that MAY be a big contributor to why some Java-supporters haven't been promoting the terrain demo so widely.

Perhaps you don't understand what "scripted" means? It means that the java is controlling other code, in a different language to the other code. Where is all the "hard" work of drawing those graphics coming from? Is it java code? (my assumption was no - perhaps I am wrong) Is it OpenGL hardware? (my assumption was yes - in which case, the Java code is just scripting layered upon system-level code (i.e. a C++/ASM DLL that is actually doing system-level tasks, such as interfacing to hardware).

I think you are missing the whole concept of what Java does. You might as well say that any C++ code that uses openGL is delegating all the 'hard' bits to the OpenGL libraries, drivers, and hardware.

Is it then "dirty" C++? Not to be called pure C++ because part of the result is done by a powerful graphics chip, and some of the drivers are written in assembly? That's just crap.

Java is ALWAYS bound to a native subsystem. Binding it to the OS code that draws graphics in ANY way would make in 'unpure' by your definition. So Java2D wouldn't even count.

As I understand it, in the terrain demo, NONE of the main logic is implemented in native code. It only makes OpenGL calls - exactly like any C++ demo would. OpenGL device drivers should not be expected to be written in Java!

I'm obviously doing something strange here, because everyone is misunderstanding me, and it seems like most aren't even reading to the end of what I've written!

The "concept of java" is three things; that's the source of the problem - because people often think of it as one or two of those three, and conveniently forget a third. Why do people tell me I'm talking "crap" or carping on about a " "pure" java", when all I'm doing is repeating out loud what Java actually is? I don't like the present arrangement AT ALL; but for some reason, instead of complaining to someone who controls the definition (e.g. Sun's marketing dept), you insist on denouncing what you allege to be my "pure" definition of java.

Quote

You might as well say that any C++ code that uses openGL is delegating all the 'hard' bits to the OpenGL libraries, drivers, and hardware.

Is it then "dirty" C++? Not to be called pure C++ because part of the result is done by a powerful graphics chip, and some of the drivers are written in assembly? That's just crap.

PLEASE READ the three things - Java is MORE than a syntax for a programming language - it is MORE than C++. This is NOT MY FAULT, I am merely pointing out the status quo. Sheesh. Why do you all seem to think I have some kind of concern about "purity" or "cleanness"? I couldn't care less - but the word "java" means those three things, and who am I to argue with fact?

Quote

Java is ALWAYS bound to a native subsystem. Binding it to the OS code that draws graphics in ANY way would make in 'unpure' by your definition. So Java2D wouldn't even count.

I said exactly that about Java2D myself! And please dispense with this "pure" moniker - this is NOT my definition, it is the one that Sun has given to the world. Don't shoot the messenger!

Quote

As I understand it, in the terrain demo, NONE of the main logic is implemented in native code. It only makes OpenGL calls - exactly like any C++ demo would. OpenGL device drivers should not be expected to be written in Java!

Yes. But the *impressive* part of the demo (which presumably is what matters, since the whole conversation started with Cas remakring that despite it being impressive, it got little recognition) is NOT the main logic - logic-wise, it's a crappy terrain-viewer; doesn't even have 6 DOF.

An OpenGL demo written in C++, where the C++ isn't really doing much, will typically be called an OpenGL demo, because it's mainly showing features of OpenGL - not C++.

Give me a demo which does something funky with templates, and I'll call it a C++ demo, showcasing C++ features.

Guys, if you can't accept what Java is, and means, fine. Don't tell me about it. I've researched programming languages going back 30 years, and know more than I'd like to about what a programming language "is", and I hate Sun's crummy avoidance of the murky issue of "What is Java?". So I *cannot* argue for their definition of Java (which you seem to want me to).

Next time someone ponders something, like Cas did, I shan't bother offering an explanation; clearly the result is that everyone assumes it was my idea in the first place, it's all my fault, and that by telling me "it's crap" (and why its crap) they can pretend it was just a personal opinion, rather than an uncomfortable truth.

No-one said it is. But currently Java IS three things, and you cannot just arbitrarily decide to ignore any of the three - they are declared indivisible by Sun. You are attempting to re-define Java as being just 2/3 of what it actually is.

I'm not ignoring platform independance or trying to redefine things at all. In fact I think platform independance is a very strong point for java.My point is that there is no point in ignoring platform specific features in the name of 'pure java'. Especially where games programming is concerned.There's still huge advantages in developing the game in java even when it's 'not pure'.And portability is still one of them, even if a little DLL is involved.

Quote

Perhaps you don't understand what "scripted" means?

You're not going to make us believe that q3 is openGL scripted by C++, are you?

To me Java is 2 things. A language and a runtime environment.*edit* throw bytecode in there if you want, it doesn't change the rest of the argument. *edit*

Both are evolving. The runtime environment is expanding. It is modular in the sense that there are 'standard extensions' and 'endorsed standards'. These extensions have the option of binding new native code and OS features into the runtime. If OpenGL is added as an extension it is simply a binding to a 3D API. As it says above.. is Quake 3 a scripted OpenGL example? Not many would say so.

Is the terrain demo using openGL - yes. But if all of the open GL calls are simply passed on directly from Java. Then the demo is written in Java to the OpenGL API. To me it is a Java program.. with help from a runtime extension. The key is that the extension is not a terrain generator.. it is basically a 3d rasterizer. Not many people write those from scratch anymore.. it is up to OS modules and graphics drivers.

If you were to write the same demo in ANY language you would not first port the insides of OpenGL to that language.. you would link to the openGL system that was already available. That's not cheating, it's just good sense.

Quote

Perhaps you don't understand what "scripted" means? It means that the java is controlling other code...

Whatever.... that could describe ANY program running on ANY operating system, as unless it is a device driver, you have no display, input or output of any kind without calling the operating system... That's just your program calling other code.

That's what programs do. Do it C++ do it in Java, I don't care. But whatever language you choose to do it with, that is the language you are writing it in. Whatever runtime you run it in that is the runtime you are running it under, etc. If you can find a compatible runtime on Linux or Mac and your code runs there as well, great. I think you are arguing more about porting the OpenGL bindings used in the demo, than is this "java" or not.

The issue is clouded with what is considered part of Java and what is not. Obviously some native binds are part of java, they have to be. It shouldn't be a stretch to say that other native bindings can be added to Java. Java3D did it, Java 1.4 added fullscreen and hardware acceleration things and did it. Is it only because Sun did those things that it is still "java".. Sun allows for extensions... small layers of native code can be included in them.

This is all just not worth arguing about. The terrain demo is a OpenGL demo done in Java. As far as I know none of the 'hard' bits were coded with anything but Java. Only a small wrapper. Do some of the 'hard' bit run outside of the JRE. Not in any non-java way. They are pulled in to the Java environment by the native bindings. But the coder of the demo still didn't have to write them himself.

Why do people tell me I'm talking "crap" or carping on about a " "pure" java", when all I'm doing is repeating out loud what Java actually is? I don't like the present arrangement AT ALL; but for some reason, instead of complaining to someone who controls the definition (e.g. Sun's marketing dept), you insist on denouncing what you allege to be my "pure" definition of java.

I don't really feel the need to start complaining at Sun's marketing dept because they distinguish between 'pure' and 'unpure'.I think I can make up my own mind about what java does for me and what it doesn't.I am also not complaining to you, I'm just argueing. Maybe I shouldn't have used the word 'crap', but 'I strongly disagree' or something cos I have the feeling the word went ...err.... ;Dsouth and offended you. If it did, then I'm sorry. Once again, I was just argueing.Argueing about you saying the terrain demo is not a java demo because Sun may or may not have a different view about java. And because it's a crappy openGL demo scripted by java.I just don't think that way and let's just leave it at that.

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