Chocolate Strife: A_FireSigil

Jon said:

I'd be inclined disagree, citing Minecraft and a bunch of Android games;

What makes you think that Android games are written in Java?

Graf Zahl said:

What makes you think that Android games are written in Java?

I said "a bunch of", not "all"; and I said that quite simply because some are.

Gez said:

It's apparently a terrible language for data manipulation, if we judge by the hoops Maes had to jump through in order to get Mocha Doom to do stuff like read WAD records and make the renderer work to generate an image that can then be displayed.

Mocha Doom is a transliteration of the existing C sources into Java. Writing code as you would another completely different language requires lots of hacks and ugly code.

If you were to write an actual more true to (desktop) Java program, you would be using FileChannel and use ByteBuffer to access the WAD data. Then if your platform and target supports it, you can memory map a ByteBuffer. ByteBuffers also can be set to read/write as little endian also (they default to big endian) so you never have to byte swap, ever.

There are no hoops to jump through unless you put them there yourself, so take the existing Doom sources which are in C and add some rule such as not using any pointers and pointer types at all. Doom can work without pointers, but the code will take a readability and complexity hit, then you can say that "C is apparently a terrible language for data manipulation".

Graf Zahl said:

If that wasn't the case the language wouldn't really be that bad (that is, of course, if it could be uncoupled from its inane runtime environment...)

The bare minimum requirement needed for the Java language to work is only about a dozen or so classes (Object, Class, boxed types, and exceptions). Java Card and J2ME/Java ME do not have reflection, serialization, or finalization at all.

Mocha Doom is a transliteration of the existing C sources into Java. Writing code as you would another completely different language requires lots of hacks and ugly code.

Exactly. You're sort of asking for trouble if you try to convert a program that depends heavily on C features like static sizing of structs into a language like Java, where that's a completely foreign concept that misses the point of the language completely.

Also, I imagine most Android games *are* written in Java, since the only real way to write applications outside of the (Java) SDK for Android is to use the NDK, which is supposedly very inconvenient to work with.

Java is still a terrible language to write most games in though, and I don't care that Minecraft used it. Minecraft is a terribly laggy game, more than it needs to be anyway, and much of that is just due to the fact that the JRE simply can't keep up with it. Seriously, just play any other clone of Minecraft like Minetest or something that's written in a language with decent performance and you'll find they run about 5x better than Minecraft on all kinds of hardware.

GhostlyDeath said:

Mocha Doom is a transliteration of the existing C sources into Java. Writing code as you would another completely different language requires lots of hacks and ugly code.

If you were to write an actual more true to (desktop) Java program, you would be using FileChannel and use ByteBuffer to access the WAD data. Then if your platform and target supports it, you can memory map a ByteBuffer. ByteBuffers also can be set to read/write as little endian also (they default to big endian) so you never have to byte swap, ever.

Don't overlook that fact that Mocha Doom can now play vanilla demos in sync! To even attempt such a thing is not only brave :), but presents it's own justification for the style of the code. You simply do not get vanilla demos working, without being byte-for-byte compatible where it counts.

GhostlyDeath said:

using FileChannel and use ByteBuffer

That's why I said "apparently", if I were confident Mocha Doom did things in the best possible way I would have omitted this qualifier.

Do you think you could (if you wanted to, that is) rewrite Mocha's file access code to use ByteBuffers without having any side-effect on the rest of the program?

sheridan said:

Also, I imagine most Android games *are* written in Java, since the only real way to write applications outside of the (Java) SDK for Android is to use the NDK, which is supposedly very inconvenient to work with.

That's what middleware is there for. Do you really believe that professional developers make a game in Objective-C for iOS and then port that to Java for Android?

No, the goal for any efficient developer is to abstract the game logic from system dependent code as much as possible. I have written countless apps for both platforms, using Java only for the stuff that needs to interface with the operating system.

Microsoft also has made direct native development a feature in Visual Studio 2015.

Gez said:

Do you think you could (if you wanted to, that is) rewrite Mocha's file access code to use ByteBuffers without having any side-effect on the rest of the program?

Probably could, but I would not.