Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Grinvon

Source port for Java?

Recommended Posts

Hi there,

I want to know if there are some port of Doom II source code for Java?

Where can find out about these kind of source under Java?

Thanks all!

Share this post


Link to post
In one of the threads Grazza pointed to, JavaGuy said:

Java will in fact be better for game programming than even C++


I doubt this. I'm pretty sure the fact Java is interpreted will always be a bottleneck.

Share this post


Link to post

As long as you have to code the renderer in Java it probably will never work (unless you have a JIT compiler.) An interpreted language with no direct system access is simply too slow for that. The game logic is another matter. It was designed for systems which are 50-100 times slower as today's fastes machines so the interpretation overhead isn't that critical.

But the biggest problem would be Java itself. The language is simply not suitable for handling the type of data Doom uses efficiently.

Share this post


Link to post

I think the whole speed issue is hugely overstated. Modern JVMs are JIT-compiled, giving the advantage of native compilation. I myself have written OpenGL games in Python (which is far slower than Java), which have been very playable. Someone I know, for their University project, wrote the same game in C++ and C# and found hardly any difference in execution speed.

People care too much about optimising and processing speed. Doom is a twelve-year old game, and I bet that even with the reduction in speed from running in the JVM it would still be possible to get a working game, especially if the Java-3D APIs were used.

You say that "the language is simply not suitable for handling the type of data Doom uses efficiently". The fact is, efficiency doesn't matter as long as the game is playable.

Having said all this, a Java Doom port would be almost impossible unless written from scratch because of the heavy dependencies of the Doom source on the C language.

TheDarkArchon said:

I doubt this. I'm pretty sure the fact Java is interpreted will always be a bottleneck.

Plenty of people run Doom in DOSBox, which is also an interpreter!

Share this post


Link to post
fraggle said:

I think the whole speed issue is hugely overstated. Modern JVMs are JIT-compiled, giving the advantage of native compilation. I myself have written OpenGL games in Python (which is far slower than Java), which have been very playable. Someone I know, for their University project, wrote the same game in C++ and C# and found hardly any difference in execution speed.


Don't forget that a considerable amount of processing time is spent in system libraries when using OpenGL. Logically this code is not affected by the speed of your own code.

People care too much about optimising and processing speed. Doom is a twelve-year old game, and I bet that even with the reduction in speed from running in the JVM it would still be possible to get a working game, especially if the Java-3D APIs were used.


Well, considering that my debug build of GZDoom is considerably slower than the release build (due to non-optimized code) I don't think that it is this easy. The bottleneck is not the rendering code itself but the preparation of the game's data for the hardware. With modern games that use much more hardware-friendly data structures this might not be such a big issue but Doom is not particularly optimizable for that.

You say that "the language is simply not suitable for handling the type of data Doom uses efficiently". The fact is, efficiency doesn't matter as long as the game is playable.

Having said all this, a Java Doom port would be almost impossible unless written from scratch because of the heavy dependencies of the Doom source on the C language.


Isn't my conclusion and yours the same in the end? There's so much code in Doom that in one way or another depends on the way C(++) is doing things that porting it to Java won't be easy.

Share this post


Link to post
TheDarkArchon said:

rapid development speeds of Java



All lies and propaganda!

The limitations of Java may reduce the risk of certain bugs but they certainly do not increase speed of development. Quite the contrary in fact because some things that are trivial to code in C or C++ are a pain to do in Java.

Share this post


Link to post
Graf Zahl said:

All lies and propaganda!

The limitations of Java may reduce the risk of certain bugs but they certainly do not increase speed of development. Quite the contrary in fact because some things that are trivial to code in C or C++ are a pain to do in Java.


That depends entirely on what you're doing. We're using C# at work for a very complicated program that communicates with medical devices, and I can tell you that if we were using C++ the development time would be massively increased.

You work on software for cell phones, don't you Graf? I don't think I've ever seen a developer praise a cell phone Java implementation, so in your domain it might be different.

Share this post


Link to post
david_a said:

I don't think I've ever seen a developer praise a cell phone Java implementation, so in your domain it might be different.



It's not just that (which indeed is a constant source of problems) but also the lack of certain programming elements (most importantly function pointers) that make developing for Java so annoying.

And this particular lack of feature is also what would make a Doom port quite impossible. Doom's entire engine design depends on them.

Share this post


Link to post

Your comment about function pointers raise an important point: Java is not designed to allow backwards-compatible designs with something like C++. Using function pointers in C++ is a solution to a problem that would be handled totally different in Java. Porting something from C++ to Java isn't just a matter of rewriting code, the design itself most likely has to change significantly.

So your comment about Doom being impossible to implement in Java is probably true... I'm certain it's possible to write a 3D engine in Java that does everything that Doom does, but it would probably end up being more like Vavoom in the sense that the end result to the user is roughly the same but the backend is completely different.

Share this post


Link to post

david_a said:
Your comment about function pointers raise an important point: Java is not designed to allow backwards-compatible designs with something like C++. Using function pointers in C++ is a solution to a problem that would be handled totally different in Java.



Yeah, the only solution besides creating a shitload of tiny classes is one huge switch with a lot of cases. And now take a guess what is the biggest problem we are constantly facing with Java. It's impossible to create efficient code with a language that never cared one bit about performance...

Share this post


Link to post
Graf Zahl said:

Yeah, the only solution besides creating a shitload of tiny classes is one huge switch with a lot of cases.

What's wrong with creating a shitload of tiny classes?

Share this post


Link to post
fraggle said:

What's wrong with creating a shitload of tiny classes?



Everything - from processing overhead to memory consumption to whatever. It's pure bloat necessitated by the languages inability to provide better solutions. This kind of code fragmentation is not what I'd call good design.

Java is a perfectly worthless language if you need jump tables. It's impossible to do it in a clean and efficient manner.

Share this post


Link to post

Java is different from, not worse than C. Live with it.

Edit: It seems the views on Java here are stuck in some sort of late-1990's time warp. Java has CHANGED ALOT. So have PCs in general. It's not as bad as it was back then.

From the way you guys talk about it, the only good implementation of Doom would be on custom hardware made specifically to run it, with all-assembly code.

Share this post


Link to post
udderdude said:

Java is different from, not worse than C. Live with it.



Java sucks. And that's my professional opinion. Like most high level languages it's perfectly adequate for 'normal' needs but the moment you have to work outside normal parameters it fails utterly and miserably.

Too bad that much of my work is exactly that.

Share this post


Link to post

Graf Zahl said:
But the biggest problem would be Java itself. The language is simply not suitable for handling the type of data Doom uses efficiently. [/B]


Call me a noob if you want, but since their is a port of Quake 2 to jave that runs extremley well on my machine (2.8 ghz PC) and claims to run almost as fast as the orginal Quake 2 exe, why shouldn't it be feasable for Doom?

http://www.bytonic.de/html/jake2.html

Share this post


Link to post

Quake 2 is a polygon based engine so it translates much more naturally to a hardware rendering API. Doom requires much more processing overhead to get things going. You might get away with something that renders small levels but some of the huge monsters out there already slow the engine down noticably when run in optimized C(++) code. How shall such levels perform in Java?

And don't forget that despite being programmed in C, Q2 is significantly more object oriented than Doom which makes a translation to Java somewhat easier.

And regarding the speed of such a port, a well implemented hardware renderer spends most of the processing time inside the system code so the slowdown isn't that noticable.

Share this post


Link to post

Graf Zahl said:
You might get away with something that renders small levels but some of the huge monsters out there already slow the engine down noticably when run in optimized C(++) code. How shall such levels perform in Java?

Who cares? Those levels aren't even DOOM, properly speaking. A port of a game is one thing, a port of its mods another (more so when considering mods made reather recently for systems quite unlike the ones used for the game years ago.)

Share this post


Link to post
Graf Zahl said:

Everything - from processing overhead to memory consumption to whatever.

Do you have any quantitative evidence that it is actually a problem or are you just assuming/guessing this is the case?

Considering we all have screaming fast processors and a shitload of memory in our modern machines, who cares?

Share this post


Link to post
fraggle said:

Do you have any quantitative evidence that it is actually a problem or are you just assuming/guessing this is the case?

Considering we all have screaming fast processors and a shitload of memory in our modern machines, who cares?



I care when some badly written software requires more resources than necessary. Why do we need 1GB for the same functionality today that required 128 MB only 2-3 years ago?

Share this post


Link to post
Graf Zahl said:

Yeah, the only solution besides creating a shitload of tiny classes is one huge switch with a lot of cases.


Creating a lot of classes wouldn't really be a problem: many would be created as anonymous classes inline where they weren't needed in more than one place.

Java uses generics to do what C uses function pointers with. Both are clunky ways to achieve higher order functions.

Share this post


Link to post
Graf Zahl said:

I care when some badly written software requires more resources than necessary.

Under your logic, 99% of all software is probably "badly written" because it uses more resources than it theoretically could if written differently.

Why do we need 1GB for the same functionality today that required 128 MB only 2-3 years ago?

We don't: it's just less of an issue than it was 2-3 years ago. If a program uses four times as much memory/processor power, it doesn't really matter, because we have bigger processors and more memory.

This lets us do things that were previously not possible, the example here is using high-level languages to write games in. I personally believe that there are great advantages for programmers if they are able to use high-level languages instead of C/C++. Note that I am not specifically saying Java is the perfect language for this task, but speaking about higher-level languages in general, it's a good thing.

Share this post


Link to post

Well, Java does not mean we're talking about personal computers. Mobile equipments still do not have limitless resources, especially RAM. And Java is known to be very inefficient with memory management, especially if more than one Java app is running at the same time.

Inefficient code: I got a pet engine based on doomsrc, running lightning fast with a D3D renderer in debug build, dynlights, huge open maps, whatever. I did not care about efficiency until I rewrote the automap to use linelist primitives instead of directdraw. And the automap became choppy with huge detailed wads. A ridiculous thing, I managed to get sublime performance in the automap mode of Doom with a 2.8GHz CPU. The problem lied with my implementation of the rendering linked lists. It wasn't buggy, just badly written.

Anyway, I'd love to see a Java port of Doom. Because of C#.

Share this post


Link to post
rpeter said:

And Java is known to be very inefficient with memory management, especially if more than one Java app is running at the same time.


I was under the impression that 1.5 fixed most of the egregious memory issues since it incorporated Apple's tricks on sharing memory between different programs. The mobile runtimes could very well be lagging in features, though...

Anyway, I'd love to see a Java port of Doom. Because of C#.


? Are you saying you would want a C# port, or that you would like to see it in Java to spite C#?

Share this post


Link to post

If I see that a Java port is possible (done), I might try my hands at a C# port. For no real reason, just for the challenge. I don't want Java because I would need to learn OpenGL as well and I had enough pain with D3D.

Share this post


Link to post
rpeter said:

If I see that a Java port is possible (done), I might try my hands at a C# port. For no real reason, just for the challenge. I don't want Java because I would need to learn OpenGL as well and I had enough pain with D3D.


D3D is renowned for being tough to program with. OpenGL has the advantage of being a standard and therefore there's still the vague chance of keeping a port cross platform. Mind you I've heard that most stuff is done with non-standard extensions to OpenGL nowerdays.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×