Announcement

Collapse
No announcement yet.

There Is A Minecraft Mod Being Worked On To Support Vulkan

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by startas View Post
    2.1) You can test windows 10 version or any other clone, written in c or c++ - its huge improvement on resourses management and overall game performance,
    2.2) Therefore minecraft currently is not bound by cpu or gpu, but by java
    Logic fail detected.
    The c++ version comes from the mobile version, the one where they HAD TO optimize A LOT their CPU code because on mobile the CPUs are weak.

    Java is meh performance-wise, but shouldn't be so fucking heavy per-se given the game is really simple graphics-wise.

    The java engine of Minecraft for PC is coded like crap, that's the main issue.

    Comment


    • #12
      Originally posted by computerquip View Post
      It's not *that* great, especially given its age and the budget it has had.
      Not to you, maybe. Some might wonder why the blazes people would even bother with World of Warcraft, yet it remains to this day by far the most successfull MMORPG of all time. Is Minecraft truly great? Minecraft is about so much more than merely its gameplay. The vanilla gameplay is very thin, I'll grant you that. But it has such an active modding community that you can basically take it anywhere you want.

      Regarding its performance -- Vanilla, it does indeed run quite shit but there have been optimization mods for years now that'll make it behave very nicely indeed. Which is not to say I don't welcome this Vulkan renderer. Anything that can be done to improve performance is more than welcome.

      Comment


      • #13
        The funny thing about this is, that Minecraft belongs to Microsoft nowadays

        Comment


        • #14
          Originally posted by starshipeleven View Post
          Logic fail detected.
          The c++ version comes from the mobile version, the one where they HAD TO optimize A LOT their CPU code because on mobile the CPUs are weak.

          Java is meh performance-wise, but shouldn't be so fucking heavy per-se given the game is really simple graphics-wise.

          The java engine of Minecraft for PC is coded like crap, that's the main issue.
          Thats practically the same thing. Java initially was chosen for faster development and more automatization. The game is not heavy, but native version gets drowned in chunks loading.

          Comment


          • #15
            Originally posted by startas View Post
            Thats practically the same thing. Java initially was chosen for faster development and more automatization. The game is not heavy, but native version gets drowned in chunks loading.
            Java version is coded like crap, period.
            It's not java per-se, it's deliberate design choices favoring easy development over performance that cause it do run like crap.

            Comment


            • #16
              Originally posted by juno View Post
              The funny thing about this is, that Minecraft belongs to Microsoft nowadays
              Yeah, they bought it soon after I started playing it. Just like they bought Skype soon after I started using it... I sense some pattern here.

              Comment


              • #17
                Originally posted by starshipeleven View Post
                Java version is coded like crap, period.
                It's not java per-se, it's deliberate design choices favoring easy development over performance that cause it do run like crap.
                I would argue: given Java's "allocate everything on the heap" approach, it's sort of impossible to implement a real-time renderer (and world simulator) efficiently. I've used LWJGL recently for a simple university project, and - as a C++ programmer - I tried very hard to avoid frequent allocations (e.g. in every game loop iteration) in general, but it has quickly become pretty annoying... 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...

                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.

                To be on topic: if I'd write a renderer for a Minecraft-like game (which I actually do, and it's pretty fun!), I'd write the remaining pieces myself too. I mean, given MC's obfuscated Java code without a well-defined interface (Modding API - how many years ago did they promise it?) it's not really worth binding to it. With some more work one can write a simple world generator and use that for a fun project like this.

                Comment


                • #18
                  Just made some modifications to the project in order to compile it on ArchLinux...
                  https://github.com/ngkaho1234/nova-renderer
                  Last edited by ngkaho1234; 13 June 2016, 11:01 AM.

                  Comment


                  • #19
                    Even still, the barely gl2.1 style renderer could use a lot of improvement, such as instancing, UBOs, and other stuff.
                    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.

                    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.

                    Comment


                    • #20
                      Originally posted by VikingGe View Post
                      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.

                      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.
                      new LWJG supports newer GL versions.

                      Comment

                      Working...
                      X