There Is A Minecraft Mod Being Worked On To Support Vulkan

[elect]

I would argue: given Java's "allocate everything on the heap" approach

False. You can allocate it also natively, and you have to take care of the deallocation yourself in that case

I tried very hard to avoid frequent allocations (e.g. in every game loop iteration) in general, but it has quickly become pretty annoying...

You could have avoided a lot of frustation if you had asked for help, the answer is pretty simple, use pools.

Where you use a simple float[3] (or some vector class) on the stack in C++ with no effective performance penalty, in Java you have to change that local variable to a FloatBuffer (ugh!) member variable and explicitly use FloatBuffer's unintuitive interface to get/set the values. And you have to do this to every frequently used vector...

In java you don't have to change anything, you simply use native buffers from the begin whenever you have to deal with GL resources.
Althought I agree the interface may not be so intuitive, easy and clean like a simple float array.

Of course you can just simply "new" everything, but it'll stress the hell out of the GC, (depending on the type of the GC) causing longer collection times and bigger memory consumption. Or, you can use bare floats instead of vectors, but the you have to write lots of boilerplate code, and you still have to use those ugly *Buffers to exchange data with LWJGL/OpenGL.

Simple "newing" everything is just wrong design. It's not java's fault, it's yours, you are overabusing one of its core feature.
Java is all about readability and incapsulation, you don't have to write a lot of boilerplate. Again, ask for help/suggestions or search online for documentation/tips instead trying everything in your own and get frustated by the ugliness of the code you wrote.

Well, Java and its lack of something comparable to a struct doesn't exactly promote the use of anything lower-level than GL 1.1 plus shaders - I haven't ever worked with LWJGL myself, but even basic stuff like filling a vertex buffer with meaningful data is probably a pain if that data cannot be represented by a simple float array. At least on the backend side of things.

Java has class since a long time. And in the class itself you can write a method to write data to the buffer.

That's probably one of the reasons why the Nova renderer is written in C++. I can't imagine that using Vulkan directly from Java would result in anything more efficient than using glBegin/glEnd, simply because Java isn't suited for working with arbitrary data on a low level.

Every language has its pro and cons. Many people tend to blame the language itself instead of their own scarce knowledge of it.

Java can perform very close to C, trading a small penalty for a lot of benefits, https://github.com/elect86/glTest

[VikingGe]

new LWJG supports newer GL versions.

LWJGL actually even supports Vulkan, it's a quite modern library. But that's not the point I was trying to make - using lower-level APIs such as GL or Vulkan efficiently while still maintaining that 'pure OOP' style of programming that Java tries to force on you is a lot harder than doing it in a language that is actually designed for low-level use cases like that, such as C, C++, or even Rust.

Java has class since a long time. And in the class itself you can write a method to write data to the buffer.

No, a Java class is something completely different from a simple C struct. C structs have a defined memory layout (something that Java actually wants to hide from you), can be used in arrays (rather than just pointers to them) and have no virtual inheritance overhead. If you want your vertex buffer to look something like this...

struct JointData {
  uint16_t jointIDs[4];
  float jointWeights[4];
};

...then you're basically screwed with Java ≤8 because the only way to represent a structure like that is to use a byte array. And telling every single vertex object to somehow write itself into a byte array (or byte buffer in LWJGL terms) is arguably not nearly as efficient as an old-fashioned memcpy (for mapped buffers) or glNamedBufferSubData. The link you posted basically proves that.

Sure, you can work around that in this case by creating individual buffers for float data, integer data etc. and using glNamedBufferSubData only (rather than using mapping), but don't tell me it's not a rather serious restriction. And I'm repeating myself here, this restriction exists because you are effectively trying to do something that Java just is not made for.

Every language has its pro and cons. Many people tend to blame the language itself instead of their own scarce knowledge of it.

You basically accuse me of ranting against java without having any clue about it. I might not have as much in-depth knowledge as you do, but I still know what I'm talking about.

True, I don't like it much in general, but application/framework development is what it is best suited for. There's a reason why, for instance, audio encoding libraries written in Java aren't exactly common (though I've seen one floating around somewhere), whereas a high-level framework linking such libraries together for convenient use is something that can definetly be done in Java.

[b15hop]

What do you think about the problem of old OpenGL version that causes lots of stuff to be done on the CPU that can by using newer versions be done on the GPU?
What do you think about Minetest (http://www.minetest.net/) and Terasology (http://terasology.org/) .

Just tried minetest. I think minetest is crap. Sure it runs smoother, but graphics are a joke compared to some of the official minecraft pixel shader mods out there. The reason minecraft was so popular was the fact that java is easier for the average joe to just jump in and mod. Compare that to C or C++ which requires a lot more effort and thus less ROI.

[elect]

No, a Java class is something completely different from a simple C struct.

You complained because java lacks something comparable to a struct. This doesn't imply it must necessary behave the same from a memory point of view. But there are a couple of workaround about that.

...then you're basically screwed with Java ≤8 because the only way to represent a structure like that is to use a byte array. And telling every single vertex object to somehow write itself into a byte array (or byte buffer in LWJGL terms) is arguably not nearly as efficient as an old-fashioned memcpy (for mapped buffers) or glNamedBufferSubData.

I don't get, are we talking about performances now?

Because I don't see the point, all of us know that, it can't never be so efficient as an old-fashioned memcpy given the nature of java.

Sure, you can work around that in this case by creating individual buffers for float data, integer data etc. and using glNamedBufferSubData only (rather than using mapping), but don't tell me it's not a rather serious restriction. And I'm repeating myself here, this restriction exists because you are effectively trying to do something that Java just is not made for.

It's subjective, it's a relative serious restriction yes, but for me it is somehow reasonable given all the advantages I get back.

Ps: however you can have just one byteBuffer for that jointData.

You basically accuse me of ranting against java without having any clue about it. I can assure you, that is not the case.

Not you in particular, it was more a general observation.

True, I don't like it much in general, but application/framework development is what it is best suited for. There's a reason why, for instance, audio encoding libraries written in Java aren't exactly common (though I've seen one floating around somewhere), whereas a high-level framework linking such libraries together for convenient use is something that can definetly be done in Java.

Yep

[plonoma]

Just tried minetest. I think minetest is crap. Sure it runs smoother, but graphics are a joke compared to some of the official minecraft pixel shader mods out there. The reason minecraft was so popular was the fact that java is easier for the average joe to just jump in and mod. Compare that to C or C++ which requires a lot more effort and thus less ROI.

Your argument: Minetest graphics are a joke COMPARD TO Minecraft MODS!!!
Are you kidding me NOOB?
Minetest has an official mod API using Lua, the programming langauge Lua, not C or C++.

https://www.lua.org/about.html

[b15hop]

Your argument: Minetest graphics are a joke COMPARD TO Minecraft MODS!!!
Are you kidding me NOOB?
Minetest has an official mod API using Lua, the programming langauge Lua, not C or C++.
https://www.lua.org/about.html

Have you even seen Minecraft being run with shaders? It looks frigging amazing. Puts Minetest to shame.

Otherwise, I'm not sure why you like Lua so much? Yes I hate Java, and yes Minecraft would probably run 10x faster if it were done in C but that's all something we can dream about because it doesn't exist (yet). I bet minecraft 2, if M$ release it, will be a visual masterpiece but probably won't be as much fun as vanilla MC. I personally wonder if microsoft will even allow modding of any new version of that game anyway. So to me, the golden era of survival sandbox fps is going to end soon if it hasn't already.

You also probably don't realise that I'm a FTB and Tekkit fan. To me minetest is like going back to the early stages of MC before it had any complexity. I've put thousands of hours of game time into Tekkit alone. So playing minetest, which feels unfinished makes me just want to go back to tekkit which I'm already starting to get bored of.

[b15hop]

Why do my replies have to be approved. Did phoronix get hacked or something...

[starshipeleven]

Why do my replies have to be approved. Did phoronix get hacked or something...

no, it is a vbullettin (forum software) "antispam feature" that returns tons of false positives.