Minecraft Forums

Yes, you should definitely use an SSD over an HDD if possible.

Just keep in mind that what matters is the world save location and game assets. What you want is the world saves and game assets to be on your fastest drive, and the easiest way to do that is to change the game directory in your launcher configuration under installations, click the three dots at the right-most position on an installation, choose edit, and put the directory of choice into the box labeled "GAME DIRECTORY". If the folder is empty, it will download assets again and install them to that directory, as well as download your chosen installation of Minecraft (unless it is modded, in which case you need to reinstall the modded version of Minecraft using the same process that you did before changing the game directory, but installing to the new directory instead).

Unfortunately, I get the feeling that you'll see noticeable improvements after installing to SSD, but they'll be subpar, probably due to other reasons. These kinds of issues will most often be due to improper configuration of the system or the game, though it can also be due to software corruption and corrupted system files, or hardware malfunction as well.

Saying that changing the render distance still causes stutters is helpful, but you didn't mention if "low or high" is referring to the FPS and what the numbers were, whether it was consistent or fluctuating, etc.

Last but not least, the last thing we might try is enabling some JVM arguments, but I want to save that for last. In my experience with the game, when I encountered stuttering, it was usually due to garbage collection and/or chunk generation, so if you're just loading a new world all the time to do your tests, and you turn your head, there is a trivial optimization implemented where the game only generates chunks in the direction that you are looking, so every time you turn your head in a new world, it has to generate new chunks, and that will often cause stutters. If you move in any direction in that new world, it has to generate new chunks.

What would also help is knowing how much CPU and GPU percentage that task manager is reporting as well.

I have an urgent announcement: the project is on!

After a very fruitful Ignatian Retreat here at St. Thomas More Priory in Sanford, FL, I am glad to announce that I am back on the project full force! Expect updates daily and public builds for testing very soon! I am also glad to accept any recruits to help me on this big project, but please realize that I am starting a business (on or after August 9th, 2018), and this project will be secondary to the business! Thank you for your continued support, and Deo gratias!
~ AMDG (Andrew Porter) formerly, link_the_programmer

Update:

Disclaimer: All information stated here below subject to change. All Names are not final.

You can also visit my Patreon for an extended explanation of why I started Quantum API! https://www.patreon.com/AndrewPorter

For now, here is a summary, the project repository, and since people have asked for it, a donate link! (I’ll get a donate button when I get the chance)

Summary of Quantum API:

Quantum API is a new API built from the ground up, and aims to solve common problems for the modding community. The goals of this API are specific, each of which accomplishes a multitude of goals:

- Backwards compatibility for mods across Minecraft versions

- A better abstraction over Minecraft than Forge

- An easy-to-use, simple API

- Backwards compatibility for Forge API

- Low maintenance for mod developers

Motivation

“We can’t find something better than what Forge already does”

.

As you all know, time and time again, we were promised an official modding API. "When is it going to come?" Insert end-of-halo-4 Cortana quote here. The biggest motivation for Quantum API, surprisingly, is not to build "The official modding API replacement". The reason I started Quantum API is because of the shortcomings of Forge API. Quantum API began back when Bukkit was DMCA'd and Minecraft 1.8 was released, and both of these happened simultaneously. Minecraft 1.8 caused the longest delay in Minecraft history, from a modding perspective. It totally rewrote the code for rendering blocks, among other things. Instead of simply defining, in Java, how each block would be rendered, you now had JSON configuration files representing BlockStates. This delayed Forge API, and as a result, delayed every mod built exclusively on Forge.

In comes me. Forge API is severely delayed for months; the whole community is still stuck in 1.7.10 land, and there is still a countable number of people using 1.7.10 today in 2018, even though Minecraft 1.8 came out September 2nd, 2014¹.

What's wrong with Forge?

There's nothing wrong with Forge API, per se, but there are some major shortcomings that do not make Forge API the best API, both from a maintenance perspective, and design perspective. To correct these problems with Forge would require a rewrite, and a complete change of paradigm, while breaking every existing Minecraft mod made with Forge. That's where I come in, to write you a new API that works, without breaking what already works.

The Infrastructure

Not everyone is meant to understand Forge, and it is quite difficult to explain programming concepts, which every programmer knows, to the average consumer like you, but I will do my best.

Structurally, Forge API consists of a mod loader and an API. Historically, the mod loader was a separated component and project, called "Forge Mod Loader [FML]", but was recently merged with the main project. It integrates with Mojang's LaunchWrapper code, code used to load old versions of Minecraft from the new Minecraft Launcher, and then applies a series of patches via LaunchWrapper as the classes are passed to FML. However, this is not a very robust system, and requires a great amount of maintenance. This is part of the reason why Forge API took so long to update to 1.8: it's just a basic wrapper around Minecraft.

The actual Forge API itself is just, as previously mentioned, a simple wrapper around Minecraft, practically 1:1. The only difference that Forge API has which makes it more than just a library for exposing obfuscated Minecraft API calls, is what little it does for mods so that they do not completely step on eachother's toes, but later on, we will read how this still fails in standard. For example, it provides a common place to register custom blocks with their own IDs while patching Minecrafts block system to allow more than 2^12 block IDs (internally, a block is stored as a 16-bit WORD in a chunk. The first 4 bits represent 1 of 16 possible states [0, 15], and the last 12 are the block ID. This has not changed despite allowing block names for in-game commands). This allows as many blocks as required to be used, and Forge also handles block id conflicts between mods.

However, configuration is still required by the user sometimes, especially in cases of mod packs, as it is usually up to the mod to define a specific block ID. However, the problem can be easily alleviated: store the original block IDs in a file with the world that only Forge recognizes, and then we know what the IDs in each chunk correspond to what block. This, of course, is not just for blocks, but for items and recipes, as well as entities, though Minecraft may still have a different implementation of each of these, but for a developer, it is quite unintuitive to shove all of these functionalities in a dictionary class called "OreDictionary".

Apart from these systems, Forge API is a simple frame around Minecraft, to put it in the words of LexManos himself, who called it, "a simple frame around Minecraft", in his own words. I can't remember if the conversation was public, but he did tell me this himself.

The final feature of Forge API that I will mention here, which fails in standard, and only prevails in convention, is "coremod" functionality. Want to modify the Minecraft API? Missing an event hook? Guess what: you can make a "coremod" for that! A coremod, rather improperly and misleadingly named, is a mod that modifies the Minecraft code itself, at runtime. Using the same LaunchWrapper system mentioned above, you can make your own patches to Minecraft for Forge to apply during initialization. Even worse, and this is where it falls apart: there is no restriction to the kinds of modifications that can be made. That's why I say that coremods "fail in standard; prevail in convention": because developers are forced to understand another mod in order to ensure compatibility with it. Last I checked, there are not just a handful of mods, but thousands of mods, all of which would be impractical to fully understand each and attempt to be compatible with.

How is maintenance for Forge then?

I am so glad you asked! In a word, I would have to imagine that maintaining Forge API and all of its components is Hell.

First, not all of the names used for classes are the most intuitive, such as mentioned for "OreDictionary" being for more than just "Ores", and only recently (the past year) has any sort of official documentation come out (mcforge.readthedocs.io). This can make it difficult to maintain, especially if you do not actively work on the Forge API, to find what you need to work on, without referring to documentation. Oh yeah, and there was no convenient documentation (from a quick Google search) prior to mcforge.readthedocs.io! Why was there no publicly available, official documentation or tutorial, available since 2011 when Forge API was introduced?

Secondly, Forge relies on MCP, or Mod Coder Pack (which came before Forge) to deobfuscate Minecraft at runtime, as well as all of the mods. If MCP didn't exist, it is arguably true that Forge would not exist either. Now, there is absolutely nothing wrong with using 3rd party dependencies. This is the exception (even if it is run by the same maintainers of both Forge and MCP). MCP is a system that uses crowd-sourced names with extremely varied naming conventions, and is constantly being updated, and especially with new Minecraft code, that means constantly updating class, field, and method names, causing much inconsistency. That means that a mod can break even by one build number!!!

Thirdly, as mentioned above, since Forge API is just "a simple frame around Minecraft" (I keep repeating this because you need to know what Forge really is, and that's why you are still reading this. Sorry, no TL;DR!), that also means that every single update to Minecraft requires an update to the API. That means adding new functionality to support the next update, but also removing functionality if the next update removed anything. In other words, your mod will no longer work because a x or y feature was removed; your mod requires x and y feature exclusively or in part; therefore, your mod is now broken, even on Forge API, because Forge API fails to encapsulate Minecraft API changes by deprecating and obsoleting old code and patching it back in for backwards compatibility.

At this point, I'm willing to say that we can now more or less agree that Bukkit, a plugin API, is more robust, secure, and easier to maintain, than Minecraft Forge, a modding API. Why does it take so much effort just to get a mod to run on Minecraft when a simpler solution exists with a simple implementation? And you still like to call Forge an Applications Programming Interface as a convenient abstraction layer for modding Minecraft? I can hardly agree!

Now, I think we've finished our rant about Minecraft Forge API; let's talk about the object, and the whole point of the above rant, of this article: Quantum API, and how it solves all of these problems in one easy-to-use package!

How is Quantum API different from Forge API?

The greatest difference between Quantum API and Forge API is the paradigm, of which defines the whole direction of any project in general: backwards compatibility. Of all the features, I am confident that backwards compatibility alone is a motivation to build Quantum API as a potential candidate for de facto replacement of Forge API, but I haven't even told you how it works yet!

Quantum API is an ecosystem

This isn't just a single little API, this is a whole working economy of its own class, and a total departure from Forge and its paradigm. No more will you need to update your mod to the latest version of Minecraft Forge just so it will run; enter the era where you, "write once, run whenever!" Yes, write your mod once with Quantum API, and you will have no need to update your mod except to add features and functionality. You will never need to make your mod compatible with "the next version" of either Minecraft nor Quantum API. Quantum API is a standalone environment, and here is how it works:

Quantum API is a multi-layer abstraction

Quantum API is a multiple-layer abstraction with multiple levels. The first layer is Minecraft itself, which has its own engine, and this is what I call the Minecraft API: the model of Minecraft. I say model because, even if the names differ, the Minecraft API still has the same structure; from a developer, more specifically, JVM standpoint, Minecraft has the same method signatures, class definitions, fields, and data--names are just for us, but computers don't need names, they just want to know what they should do.

The second layer is what I call Abstract Virtual Minecraft API [AVMA], a very crucial and important component of the Quantum Environment. The purpose of AVMA is to encapsulate the whole Minecraft API, as well as encapsulate the obfuscation of Minecraft itself. Creating AVMA allows greater possibilities and flexibility for mods, and even allows mods to add functionality to the API itself with their own extensions. AVMA is essentially a model that answers the basic question, "What is Minecraft?" Minecraft is: 1) a Sandbox game about 2) building [Recipes] using 3) tools [Items] to 4) build a house with various materials [Blocks] in order to 5) defend against various enemies [Entities] with 6) various weapons. (Of course, it's a sandbox game, so the goal is what you make of the game itself.) AVMA will have (for developers) interfaces, abstract classes, and classes for interacting with these parts of the game from Quantum API, which will be discussed in the next section, and will also expose the Minecraft Engine's implementation components such as the graphics pipeline and persistent storage implementation.

This component will be made in such a way that you can modify or make custom implementations of part or all of AVMA to modify Minecraft itself, as each part of AVMA will have a 1:1 correspondence with a particular function in Minecraft, though the names will vary greatly from the Minecraft API in structure and implementation.

Quantum API itself

The third and final layer is Quantum API itself, which is built on top of AVMA. While AVMA simply provides access to Minecraft API functionality, Quantum API is the common interface through which all mods will communicate with AVMA, and finally Minecraft itself, to achieve a desired modification or result. The higher order API functionality will be here, such as, for example, game modifications, custom blocks, custom entities, etc. all the custom game elements you can imagine. As mentioned above, AVMA is made in a way that promotes structure modification of Minecraft in a way that is standardized and promotes compatibility between mods without the developer requiring to know the implementation details of another mod.

How Minecraft Modifcations will work

This is a more advanced topic intended for developers. If you aren't a developer, it is not recommended that you read this section, unless you want your brain to hurt.

To understand how modifications to Minecraft will work, and why you would want to modify Minecraft in the first place (in such an intrusive manner as modifying the internal code), you need to understand how AVMA will work.

In short, AVMA's methods will be bound to methods in the Minecraft classes, and only methods and fields will be bound, not classes (I'll talk more about that later). The correspondence will ideally be 1:1 with a method matching exactly with a method in the Minecraft API, however, this is not always going to be the case, but from a developer standpoint, this is not a concern, as all of that is encapsulated under AVMA. When Minecraft removes functionality, AVMA adds that functionality back in.

All of AVMA's classes will have a root interface parent for all abstract and concrete classes. It is the interface and its methods (only the methods) that will be bound to Minecraft API methods or operations.

For security and maintenance purposes, some methods will not be allowed to be overridden for modification. These will be engine-critical methods such as drawing routines and low-level implementation details that are not necessary for modification and do not affect how the game works.

FAQ (preempted)

1. Why can't I modify certain methods for "security" and "maintenance" purposes?

These methods are "reserved" by the Environment for exclusive modification by Quantum API. These methods are deemed too sensitive to be used by every mod developer. Furthermore, mods like Optifine, and other low-level mods designed for "performance enhancement" rather than "game enhancement" will not be possible. however, that does not mean optimizations will not already be in place. Modification of these methods will result in an IllegalMethodTransformError, and Quantum API will terminate, as well as the client (be it the server or the client instance of Minecraft).

2.What kinds of optimizations will Quantum API employ?

As mentioned in the previous section, there are "reserved" methods for exclusive usage and/or modification by Quantum API. These reserved methods will either be untouched, or be modified to use optimized routines. Note that these methods will have actual code in them most of the time, and they will be available in the AVMA development source code, but Quantum API will actively prevent modification of such methods optimized by the API itself from any other source than Quantum.

3. Will you have a server?

That's a big, fat, obvious, YES. However, there is no point in mentioning the details as it is too early in development.

4. When will the API be complete?

Since the hiatus, and for months since before, Quantum API has been stuck in a beta state, but as the whole design has changed, and resources have been lost since then (the de-obfuscated Minecraft sources I used), the API is now back to an alpha stage. In contrast to before, however, development will be more fast-paced, and updates released more frequently. I will release updates to GitHub more or less monthly, as I usually, as of right now, make large commits, rather than smaller ones, for entire task groups, rather than making a commit for every little change. The same problem as before, however, still persists: I need to finish my JCLA library to get a proper on-the-fly (Just-In-Time) Java [10] Compiler. Don't worry, I'll support all Java versions that Oracle currently has not dropped support for. Until then, there is no due date; besides, this will be the best implementation of Quantum API ever! (The current, half-implemented source code looks a mess right now in terms of structure, planning, and maintenance, which is an anti-pattern, and makes it more like Forge than Quantum!)

That's all I have for now! Until next time...

... Deus vult!

Repository: https://www.github.com/QuantumTheoryMC/Quantum

Donate with PayPal account required: https://www.paypal.me/AndyDepot

Quote from MarioBenjamin»

I am very happy to see this project back alive again. I did not expect to see this project still alive even after all these years. I have been watching this project for 3 or so years.

I can assure you, this project will either never complete because I died, or because I became too busy with my business. Other than that, I see no reason to give this up, especially since it is potentially another income stream for me.

Coming Soon: Java 9 Optimizations!

As you know, java 9 came out! I can't wait to start optimizing a totally different garbage collector instead of the CMS: the garbage first collector, or G1GC (it will be default in Java 9)!

Welcome to the Vanilla Optimizations thread! This thread is intended to provide optimizations for the community without mods, though it is recommended that Optifine be used with these optimizations for best results.

Introduction

Instead of just giving you a list of optimizations that do something you don't understand, I'll teach you a little bit about Java and Minecraft so you that you can learn how to optimize the game yourself and know the reasons behind these modifications.

Note: before you start, do realize that these optimizations are for client only! These are not guaranteed to optimize server performance!

Audience

If you have a computer that can barely manage 30fps consistently and want to get a smooth 60fps, or you have a computer that gets a nice 60fps and that's it, but you want some more eye candy, or your computer happens to be a supercomputer and you just want the game to be the best version of itself, then this thread is for you!

About Java

Minecraft, as you know, runs on Java. Because of this, adequate understanding of the Java Virtual Machine is essential for optimization. This section will teach you about the JVM and the reasons why Minecraft may not be running so smoothly on your machine.

How Java Works

Before I can explain anything about the Java 8 HotSpot 64-bit Server VM, you first have to understand what the JVM actually does; before that, your computer.

Your computer is made up of many modular hardware components that are the result of decades of research. Inside your computer, you have a Central Processing Unit (CPU), and Random Access Memory (RAM). The CPU is simply a logical processor that interprets instructions represented in binary. Each CPU can execute a specific set of instructions, and this is called an instruction set, and these can have as few as 10 instructions, to over 100 instructions for a single CPU. The instruction set of a CPU varies from one brand to another. The most widely known are AMD and Intel. A more uncommon one is ARM (Advanced RISC Machines, RISC: reduced instruction set computer).

A program is a file containing instructions for a CPU to execute. These programs first have to be written in a human-readable format by programmers, then compiled to machine code, the instructions for a CPU. As mentioned above, the instruction set varies from one brand of CPU to the next, so programmers have to make multiple versions of the same program for each instruction set. This is a problem that is, in most cases, easy to overcome, but it has its consequences.

The solution to this problem is Java, or at least one of them, .NET being the other. With Java, you develop for a single instruction set which is an intermediary form of instructions called bytecode. The bytecode for Java is the same for every JVM, so you can write your program once and compile to this bytecode and it will run on any JVM. The JVM interprets bytecode to the native instructions for your CPU and executes it.

In the JVM, the bytecode is then optimized to native instructions rather than interpreted. It is optimized by the JIT or Just-In-Time compiler. From there, it basically runs like a native application that doesn't run on Java.

The Heap

Memory is split into different segments. One of these segments is called the Heap. This area specifically stores objects. Briefly, an object is an abstract data structure; semantically, just an array of data. Objects can reference other objects, and they can also dereference objects. When an object becomes orphaned, that is, all references to the object no longer exist, the object is available for garbage collection since the object won't be used any more. You know why Java appears so slow? This is the whole reason why: Garbage Collection.

Garbage Collectors

As mentioned before, usually the program is the problem. If the program is the problem, that can usually be bad news. In this case, doubly so, because you have two problems: Minecraft is not optimized at all, and doesn't even follow OOP at all in some cases, and on top of that, it's on the JVM using GC which is the main cause of lag spikes. I'll talk about Minecraft bottlenecks later, but generally speaking, when a programmer has exhausted all efforts to make sure the program is efficient, then you can consider the environment. This latter option is not available with native applications because that then forces users of the program to modify their environment. However, the JVM is its own environment. In this case, I'm talking specifically about Garbage Collection.

There are a number of garbage collectors available with their own strengths and weaknesses, but the best one to use for Minecraft (which Oracle has considered making the default over the throughput collector), is the Concurent Mark Sweep collector. You can read about it here. In Java 9, the Garbage First Collector (G1GC) will be made default.

Minecraft Bottlenecks

You may notice that Minecraft lags while chunks are generating. This is for multiple reasons. The first is that terrain generation uses a very intense polynomial equation to generate terrain.

The second is that these chunks with a size of width*height*depth=16*256*16 are very large, cached in memory, for a time, and when more chunks need to be loaded, the cached chunks are written to disk. In fact, chunks are written to disk almost immediately. Writing to disk, as everyone knows, is a very expensive operation.

The third reason is that these two operations are asynchronously executed in the in the main loop which is in the main thread, which means that you have to wait until the chunks are written to disk before calculations can continue. Thus, you get tremendous amounts of unnecessary lag. It would be more efficient to simply have a chunk queue on a separate thread that periodically saves chunks to disk from main memory in proportion to the rate at which chunks are generated (otherwise memory would fill up too quickly and an OutOfMemoryError would be thrown). In another thread, chunk generation could utilize a ForkJoinPool to generate chunks in a more efficient manner. When the generated chunks are ready, they could be put into the chunk cache and rendered.

Particles are particularly slow to render for whatever reason. I suspect it has to do with transparency, since fancy leaves are very slow to render as well, and lighting is actually implemented in software by the actual Minecraft engine. These bottlenecks can only be overcome with faster hardware, or with mods (so consider installing Optifine, I recommend it).

Another problem is that Minecraft actually runs on the old fixed function pipeline in OpenGL instead of the core OpenGL profile (Version 3.1+) with modern functionality such as GLSL Shaders. Shaders are faster and more flexible than using the Fixed Function Pipeline of OpenGL which is from version 1.1, and the fixed function pipeline itself is implemented in shaders.

Those are primarily the only bottlenecks, aside from other smaller bottlenecks, which are compensated by the JIT compiler anyways, or are negligible.

Optimizations

Fortunately, Minecraft is built on the JVM, and the Garbage Collector is fully configurable. It is the largest bottleneck, and it is very hairy to tune. This section will provide some JVM arguments that can be specified at initialization in the JVM Options area in the Minecraft Launcher.

-server

required. This runs the JVM in server mode. Only supported by 64-bit.

-Xverify:none

improves startup time. At JVM startup, when the JAR files are loaded, the class files are verified for security reasons, and this significantly increases the amount of time it takes to start the application. Enabling this option significantly reduces startup time in a noticeable way.

-da -dsa

"da" and "dsa" both disable assertions and system assertions, respectively. Assertions are checks which are made. System assertions are checks made in the Java API. Disabling assertions is a negligible optimization since most assertions are not very expensive, but it may add a few extra fps.

-Xms210828288

This option sets the minimum Heap size to 210,828,288 bytes (210.8MB). Minecraft does not need much memory to run at all. In fact, it can run smoothly at only a max heap of 512MB. This value is calculated based on the maximum vanilla chunk rendering distance at a radius of 16 chunks. A block is stored in a chunk by its numerical ID, which is an integer (32-bit value), which is 4 bytes. A vanilla chunk is width*height*depth=16*256*16=65,536 blocks. 4 bytes * 65536 blocks = 262,144 bytes (262.144 kilobytes). To find the amount of bytes used for a radius of 16 chunks, we use PI*r^2 (the area of a circle). 262144 * (PI * 16^2) = ~210,828,714.1331565 bytes. The JVM only takes values in multiples of 1024, so 210,828,714.1331565 / 1024 = 205,887.4161456607. We round this value to 205,887 and multiply by 1024 to get 210,828,288 bytes for a radius of 16 chunks.

The Chunk Cache

Note: you can also add a certain number of bytes to this number. The game itself has a chunk cache, and the maximum size of this cache depends on the size of the heap, so you only need to calculate the number of bytes for however many chunks you want to cache in the heap and add that to 210,828,288 bytes using the number of bytes in a chunk, so that means you can use the following function to calculate the number of bytes for Xms:

210828288 + ( number of chunks to cache * 262144 )

For the chunk cache, I personally would have at least four times as many chunks as the square of the rendering distance. If you keep your distance at 8 chunks, that means your chunk cache would be 4 * 8^2 = 256 chunks, which is 67,108,864 bytes. For 16 chunks, that's 268,435,456 bytes! This value additive value ontop of 210,828,288 bytes can definitely affect performance. If the chunk cache is too small, chunks will be generated more often, which is an expensive operation. If the chunk cache is too big, every periodic GC may have a larger and larger lag spike in proportion to the heap size. It really also depends on how many chunks you tend to explore in one session of Minecraft.

-Xmx1024m

This option sets the maximum Heap size to 1024 MB. Minecraft has 8x8 textures, but the textures are only stored in Graphics memory, so those aren't important. However, for what ever reason, if you open debug (F3), you'll notice that the Heap fills quickly, especially while you move. If you make the Heap too large, this can affect GC performance by making GC passes take longer, thus introducing unnecessary latency. The size of the Heap is directly proportional to the amount of time it takes to do one GC pass, so a smaller heap is better, and that goes for any machine—just because you have 16GB of RAM doesn't mean you should allocate 8192MB for Minecraft to use. I suggest not going higher than 4096MB.

-XX:ReservedCodeCacheSize=512m

Sets the code cache size to 512MB for compiled methods. No more than 512MB are required for Minecraft. This goes even for mods, but if you have a lot of mods, increasing this value to 768m may compensate for the extra methods added by mods. Lower values may decrease performance since the JIT compiler may run out of memory for compiled methods, and those methods will remain interpreted because they didn't fit in the compiled code cache. The absolute limit is 2GB.

-XX:+AggressiveOpts

Enables aggressive optimizations that are expected to become final in a future release. The performance increase is very noticeable.

-XX:+DisableExplicitGC

This option disables calls to System.gc(). As mentioned earlier, Mojang places that call in the game loop, so GC cycles are executed after each frame to keep memory usage low. This is a latency bottleneck, however. On my machine, this option adds 10-12fps, so I would now be getting ~42fps on average without input lag.

-XX:+UseConcMarkSweepGC

This option enables the CMS garbage collector. This is a better collector for low-latency requirements, especially realtime applications. This adds 2-5fps on its own, so now I would have 44-47fps on average. To learn what the CMS collector does, see https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html .

-XX:+CMSScavengeBeforeRemark

This option enables scavenging (collection) of the young generation before the remark stage of the CMS collector. The remark is the second (final) mark stage of the CMS collector before a full GC (sweep). The CMS tracks objects on the heap and marks objects that are unreachable for collection by the CMS collector.

-XX:+CMSParallelRemarkEnabled

This option enables parallel remark, the final marking stage of the CMS collector before a full GC. This will reduce latency which will scale to the number of physical cores available to the JVM.

-XX:+AlwaysPreTouch

This option enables touching of every page of memory. Your system uses a paged memory model which splits memory into "page" slices. When an application requests for a memory allocation, the system must find an empty page that your application can use, which may take some time. If the Heap needs to grow, then memory has to be allocated every time the heap needs to resize. This option may improve performance by allowing the heap to shrink or grow without having to allocate new pages of memory by touching all pages at initialization. Otherwise, pages are allocated as needed. The performance is very negligible, but this makes your game run a very small tad faster (less than 0.1fps), but depending on the system, this could save much since page size is usually based on the total virtual memory available and split accordingly, so a page could be 1k or 8k (and everything inbetween or higher) depending on how much memory you have.

-Xnoclassgc

Disables garbage collection of classes. This shortens GC latency, and adds maybe 1-2fps, depending on how many mods are installed, even more. Generally, a class is loaded when functionality is needed, so OutOfMemoryErrors aren't going to be a problem. Usually, even if something is only used once or twice, the size of classes are negligible, and is usually beneficial to prevent GC of classes.

-XX:-CMSClassUnloadingEnabled

This option disables unloading of classes with the CMS collector, which saves GC time.

-XX:CMSInitiatingOccupancyFraction=90

Sets the initiating occupancy percent of the old generation to 90%. This is one criterion for the CMS collector to start a CMS collection cycle (full GC). When the old generation reaches 90% occupancy, a CMS collection cycle will begin. This is one of many triggers for the CMS collector.

-XX:InitiatingHeapOccupancyPercent=90

WARNING: THIS VALUE MUST NOT CHANGE. Sets the percent of the entire heap to be filled before a full GC cycle to 90%. This is one option, in combination with MinHeapFreeRatio and MaxHeapFreeRatio, that is essential to the performance of Minecraft. I have found this to be a good balance for reducing lag spikes and stutters for minor GCs throughout execution since this means a full GC only occurs when the total heap occupancy has reached 90% capacity.

-XX:MaxHeapFreeRatio=87

WARNING: THIS VALUE MUST NOT CHANGE. Sets the maximum percent of the entire heap that is allowed to be free after a GC cycle. If after a GC cycle the amount of free memory is greater than this value, the heap will be shrunk. This value, along with MinHeapFreeRatio and MaxGCPauseMillis, make the heap tend to expand only when necessary. Expansions are more likely to occur after long sessions of Minecraft, and during initialization. These values also affect the minor GC latency.

-XX:MinHeapFreeRatio=13

WARNING: THIS VALUE MUST NOT CHANGE. Sets the minimum percent of the entire heap that is allowed to be free after a GC cycle. If after a GC cycle the amount of free memory is smaller than this value, the heap will expand. This value, along with MaxHeapFreeRatio and MaxGCPauseMillis, make the heap tend to expand only when necessary. Expansions are more likely to occur after long sessions of Minecraft, and during initialization. These values also affect the minor GC latency.

-XX:MaxGCPauseMillis=1

WARNING: THIS VALUE MUST NOT CHANGE. Sets the target maximum allowed time for GC. This is a soft goal, and the JVM makes a best effort to reach this goal. Along with MinHeapFreeRatio, MaxHeapFreeRatio, and InitiatingHeapOccupancyPercent, this option minimizes GC lag spikes (stutters). On my machine, the average GC latency is 3-13 ms with all of these default parameters. If you have more CPU cores or a faster CPU, the latency will be lower. I only have two cores at a max clock speed of 2200MHz (2.2GHz), 1400MHz on my newer laptop.

-XX:NewRatio=3

WARNING: THIS VALUE MUST NOT CHANGE. Sets the size ratio of the young generation to the old generation to 1:3. This means that, as the heap shrinks and grows, the young generation will be 1/4 the size of the entire heap compared to the old generation. Out of all the the options specified here related to GC and heap ratios, this option has the largest impact on GC latency, and thus directly affects frame rate and GC-induced lag stutters.

-XX:SurvivorRatio -EXPERIMENTAL

WARNING: DO NOT ENABLE YET UNLESS YOU KNOW WHAT YOU ARE DOING. Sets the survivor ratio between the second survivor space relative to the first, against the Eden space. For example, to set the ratio to 1/8 the size, this value would be 6 for a 1:6 ratio. That means the second survivor space would be 1/8 the total young generation size.

NOTES:

- options that I have labeled with warnings indicating the value should not be changed, should not be changed.

- options that I have labeled as experimental should not be used unless you are an expert on the matter. These options are being experimented with for their potential performance improvements.

System Optimizations

- use a faster persistent storage device: as mentioned before, Minecraft heavily relies on disk to save chunks to and from memory. This is one bottleneck that can be lessened or removed by using a faster hard drive. If not that, consider at least a large hard drive, an SSD, and USB 3.1, or any combination of the three of those. You could even setup a temporary drive that uses a portion of your RAM if you have the right software.

- on Windows, open the "Performance Options" dialog by searching for it or googling how to open it. A window with many desktop visual performance checkboxes should come up. Modify that as you like and exit. Your system will have better performance; Windows will not process certain aesthetics in Windows which will speed up your system in general. I recommend keeping "compositing" enabled, or vsync will not be available.

- on Windows 7, consider switching to a non-Aero theme or disabling Aero glass to make sides of Windows opaque. It is an aesthetic that is more demanding than you think.

- on Windows, open the "Performance Options" dialogue and click into the "Advanced" tab. Adjust the first setting for best performance of "Background services". In turn, the Windows operating system will be prioritized. As backwards as that sounds, it means the OS will stall foreground programs less when the OS decides to do something, and reduces the cost of system signals from Minecraft which means better input latency from mice, and other peripherals, while also improving desktop (explorer.exe) and application responsiveness (fewer "Not responding" problems).

- on Windows, consider deleting C: drive and installing Arch Linux to get a more efficient OS with better latency for foreground applications and full configurabioty with your system from scratch. Or just dual boot Linux.

- on Windows, consider reverse engineering kernel32.dll, user32.dll, and other Windows components, and hack Windows to make Windows run, you know, efficiently? By switching to GCD as the primary threading model and a UNIX-based networking model, then having Windows distribute across multiple cores to improve OS throughput and latency.

- on Linux, consider using a lighter Desktop Environment, or move to just a lightweight Window Manager to improve performance.

- on Linux consider faster kernels such as zen (faster) or liqourix (fastest)

- on Linux, consider KMS and Realtime priority support to improve audio latency

- on Linux, consider making a more efficient kernel than all the rest by developing a minimalist modular exokernel written in D.

- on any OS, consider making an OS specifically for running Minecraft

Note: some of the above suggestions are actually sane.

Authority: If there is any reason you should question whatever I put in this thread or reply to, you should know that I have been programming in Java since 2010. If there seems to be an error, please tell me; it is a logical fallacy to appeal to my experience and expect me to be perfect and take everything I say as correct. As of writing, I have 7 years of Java experience.

Hello, everyone! It has been about three months since my last post.

The project is not dead!

Development has been off and on. I am still working on a stable release plan. Quantum API v1.0b is complete, but without this build system for quantum, it only works on my machine.

The process involves simply renaming references to deobfuscated Minecraft code to obfuscated Minecraft code in the Quantum Wrapper.

The repository is, at the moment, empty because I changed the directory structure, and switched computers in the middle of it, and Git is stupid that way in that I can't just override the old code with my local commits; instead, it wants you to rebase with the upstream branch (synchronize my environment with the repository) before I can create a commit that deletes the old code and pushes (uploads) the new code.

At the moment, the current progress of the build system, named Quantum Build, is quite close to completion. When summer break hits, it can be expected that Quantum development will receive a significant speed up. I expect Quantum Build to finish before or shortly after summer break begins.

Pushed Again!

Sorry everyone, but a beta release is still yet to come!

No worries though! I solved the problem with Blocks not being rendered properly (turns out minecraft uses an identity-based map for mapping IBlockStates to their IDs)!

For those who don't know what that means, basically a blockstate is an object (that is defined in a JSON file, but in quantum you can just define a BlockModel however you choose). Objects can be made over and over again, and they are stored in some arbitrary address in your computer (like when mail gets delivered).

Well in our case (I'll use the mail metaphor), there is a one-to-one correspondence between BlockStates and their IDs, so if I send a green envelope to an address, that address only recognizes green envelopes.

Quantum handles this in a very easy way: now when you send your piece of mail in a different color envelope (say, blue) than your initial envelope, you send it to a proxy address to wrap your blue envelope in a green envelope that forwards the wrapped envelope to the primary target address.

For Java nerds and mod devs:

Quantum implements this using a Hashtable. It maps Block.States to UniqueStates (Wrapper specific) wrapped in an Entry object which stores the cumulative hashCode for a Block.State via its index and Block. This means that any two Block.States which are not reference-equal, but have the same properties, will return the same UniqueState.

Due to all of this, I have some refactoring I would like to do before making the first beta release, such as making the API wrapper-agnostic, and cleaning up the structure of the API (mostly Quantum.class) and Wrapper (too tightly coupled).

Until then, Quantum Beta release is TBD, with a soft deadline of Jan. 22, 2017; may be much sooner.

The Universe is Turing complete at an atomic level, and Quantum mechanics (and the majority of science, esp. physics) intrigues me, so I named it the Quantum API.

Man, I really want to use this mod. Minecraft uses cubic chunks already, but they are stacked onto each other, and are loaded at the same time in one linear chunk.

I think after I get my Quantum API working I'm going to make my own cubic chunks mod that will still be compatible with other mods. Perhaps then LexManos won't think it such a horrible idea. And in that case, people will have a stable mod working. By then, Tall Worlds mod will be finished, but only for it's own mod loader. I think this would be a big step forward.

Quote from Bumber»

But can you see the sun and moon by looking through a solid mountain? What does relativity say about that?

Actually, in minecraft, yes you can if you have a low chunk render distance when the sun or moon is setting

I don't think you understand just how easy it is to resolve that problem simply by drawing sky objects first, so any solid mountain doesn't have a sun shining through it.

Hmm... that makes sense. It still doesn't make sense to me though how he heard of it off IRC. The greatest change I noticed was when I finally made the GitHub. I was at 400 views, and then it shot up to 700 within the first 13 hours. It's still growing steadily...

This is a mod that allows you to hatch previously useless dragon eggs. Once fostered and tamed, they'll be your faithful companion in all situations and, of course, can be used for a ride!


Screenshots

Some images of a tour through the sky:



Here's an image of two dragons on ground, one of them saddled:



They can also hover midair and look at you:




For less annoyance, dragons can be told to sit like cats and wolves by using a bone on them:



Changelog

r46:

• Fixed a NullPointerException in EntityAIDragonCatchOwner.

r45:

• Dragons will fly together with their owners that glide with Elytras.
• Forest dragon now produce green grass again and improved performance of the footstep algorithm.

(Older versions:)

Download

Note: this mod is still in beta stage and has known and unknown bugs. I'm not responsible for the possible loss of dragon eggs due to bugs. Test this mod with care!

• Dragon Mounts r46 for Minecraft 1.10.2
• Dragon Mounts r46 for Minecraft 1.9.4
• Dragon Mounts r46 for Minecraft 1.9
• Dragon Mounts r44 for Minecraft 1.8.9
• Dragon Mounts r43 for Minecraft 1.8
• Dragon Mounts r41 for Minecraft 1.7.10
• Dragon Mounts r40 for Minecraft 1.7.2

GitHub repository: https://github.com/ata4/dragon-mounts

Feel free to use the source code for your own dragon mods! And please let me know about any forks of this mod you want to publish!

Note: you may distribute this mod on mod databases on your own under these conditions:

• State clearly that I made this mod. Don't play role games pretending you're me.
• Please link back to this thread.
• Use the adf.ly links if possible. (URL prefix: http://adf.ly/1327464/)
• Don't modify the package using .exe installers, it's really bad practice for security reasons.

Download and installation notes:

• Installation of Forge is required to run this mod.
• Move the Zip/Jar file in the "mods" directory inside your .minecraft directory.
• Don't forget to remove the old installation when updating!

Quick guide

• To hatch a dragon egg, you'll need to find a good place for it first. If you found one, place the egg block and simply right click it. The egg will then start to hatch, which will take a while.
• Once grown up, you can tame the dragon with raw fish. It will then follow and protect you like other pets.
• You can command tamed dragons to lay down or stand up with the bone item.
• To ride a tamed dragon, use a saddle on it, then right click it without holding an action item.
• To heal injured dragons, feed it with raw fish, chicken, beef or porkchop (four hearts) or with rotten flesh (two hearts).
• You can control the dragon with the Carrot On A Stick while riding it.

Frequently Asked Questions

Q: Is there going to be dragon armor? And when?
A: I don't know yet for sure. It heavily depends on the reusability of the inventory code of the horses, which is quite bad in the moment. It may improve in the future, though.

Q: Dragons need to breathe fire! When are they going to do that?
A: That could happen within the next few releases.

Q: How do I get dragon eggs other than from boss fights:
A: You can enable chest spawning in the DragonMounts.cfg file. Open it with a text editor and change "B:eggsInChests=false" to "B:eggsInChests=true". Or, if cheats are enabled, you can also simply
enter the chat command "/give dragon_egg".

Q: I tamed a dragon in singleplayer, but when I now try to interact with it, it says "This dragon doesn't follow your commands".
A: This could be an unresolved bug. As a workaround, you can use the chat command "/dragon tame" to reclaim the dragon.

Q: I'm a huge fan of ! Can you add for me?
A: This mod is supposed to be fandom-neutral so it's suitable for everyone. This also ensures consistency with Minecraft's look-and-feel. Therefore, I can't fulfill these special requests, sorry.
However, there are some WIP projects that may use the source code of this mod as a base for a fandom-based mod. Here are some examples:

• How To Train Your Dragon
• Inheritance Cycle / Shur'tugal

Special thanks

• Venomari245 - Forest dragon textures
• simocarina - Ice dragon texture
• Alexxx999 - Nether dragon texture and suggestions
• Gon009 - Testing and feedback
• Thaliviel - Testing, ideas and coding help
• Wulf_Oman - Ghost and Aether dragon textures
• leoslake9 - Fire dragon texture updates
• TheGreyGhost - Port of the code to 1.8
• TheOnlySilverClaw - Code improvements
• BrisingrAerowing - Port of the code to 1.10.2

My other mods

Minema
Mineshot

Quote from link_the_programmer»

Created an initial refactor finally. Quick note: This API uses only javassist, and minecraft. ASM is heavyweight and unnecessary: javassist is lightweight and satisfies my needs of modifying classes at pre-runtime with Java Agents.

Quote from link_the_programmer»

1)who cares about memory!? We care about latency! Memory comes next in optimization if at all! Because after you know it the game takes gigabytes of memory upon launch then sits at 2-3GB while playing. Versus the if even 512MB of memory vanilla uses. I've proven that vanilla Minecraft can run perfectly fine with 512MB of memory. Thinking memory isn't important is just begging for trouble, if you don't think memory is important to care about you need to rethink about everything to do with computing.
a. Explosions shouldn't have to lag, nor use ray-tracing to track blocks to break for dynamic damage. All you need is a radius for which blocks are affected, get the blocks in the affected radius, and use a function of the distance from explosion epicenter to calculate damage done to the blocks. If more TNT increases the damage of the explosion, have the radius increase by getting the distance of the other TNT from the current TNT and add that onto the radius of the current TNT if the other TNT is at or in the radius of the current TNT. Except how do you know what blocks to break versus what blocks not to break aside from using a pre-generated image as a driver for the damage "map"? The ray-tracing is used to provide the random destruction of blocks, instead of an explosion killing every block in range using the power as the radius for the look-up sphere, it spawns n rays where n is a number determined by the power and throws them out in random directions from the origin. Noise generation can get sketchy as you could destroy blocks which weren't accessible to the explosion (blocks behind obsidian, hence the obsidian protecting them) so noise generation is out, plus noise isn't exactly quick to generate either for a quality noise sample.
2) Those optimizations will be loaded as (a) mod(s). Might I add you can enable and disable mods with this API.
a. Chunks are cubic by nature, but are treated as 2D chunks (16 cubic chunks stacked on top of each other to make one square chunk for a max height of 255). Making Chunks cubic wouldn't change anything except improve chunk processing because it's not processing 16 cubic chunks per square chunk. I thought chunks were cubic, however didn't want to say anything just in case I was wrong.
b. Putting chunks in another Thread would greatly improve latency because the most obvious bottleneck in the whole game is the harddrive for writing chunks all the time, and chunk generation. Instead of generating 1 chunk per tick, you can have an arbitrary number of chunks load unconstrained by ticks in it's own thread on Thread.MIN_PRIORITY at it's own pace without affecting the game loop directly. I wouldn't call this the most obvious bottleneck, I'd just call the most obvious bottleneck poor code and lack of decisions that would put the game in a better situation for what it is now. Like, hell, the lighting system in the game is basically a hack on top of a hack and could be optimised a ton. At least they've moved forward with models and provided a semi-decent model format, not calling the JSON system a decent model format of course.
c. There's a difference between changing how the game works and refactoring the implementation to do produce the same output, but more efficiently. Refactoring the implementation affects and breaks any code that used the old implementation, especially when the way the implementation worked changes. That's what I've been saying all along. Just because 1.7.10 and 1.8 both render blocks doesn't mean mods will deal with it fine because they both result in the exact same outcome. It doesn't work that way. If method "render()" is removed in 1.8 and a mod for 1.7.10 still uses the "render()" method, Java goes "uh oh, render() doesn't exist!", mod crashes the game because it's referencing a method that is non-existent, ergo the update broke the mod. Ultimately, no backwards compatibility. There's a reason why Google Translate and the majority of other translation services introduce subtle and trivial mistakes when translating between languages; even though language is just a means to communicate a meaning between entities, just like a programming language or a function, it doesn't mean one implementation is immediately and perfectly compatible with another. This is what I've been trying to say all along and have been saying all along.
3) Never has there ever been a case in which a change in 1.8.1 changed the same version 1.8.1. One major change in 1.8.1 results in 1.8.2, at which point I update my API to compensate for the change that may be getBlock() or how minecraft registers blocks. I don't mind doing that every time there is an update, no matter how big, and I don't mind Wrapping every necessary class (models, entities, BlockEntity [known canonically as TileEntity, but proof in the source of the file in an error string shows this to be the correct name], items,and world), because everything else I can control internally without wrapper classes and only exposing the methods by wrapping them (The JIT will optimize the wrapped methods by inlining the minecraft methods within the wrapped methods, so the performance will improve in terms of nanoseconds and might free up a millisecond or less). When did I say that a change in 1.8.1 is released as 1.8.1? And I've been saying that that's what you have to do all along.

I will conclude with: the OP says "Article WIP", meaning everything I've mentioned thus far I haven't gotten to putting in the OP because it's formatting's broken for some reason...

Quote from link_the_programmer»

"Until you solve the other step for everything that Mojang can change, which is a lot, this isn't backwards compatible."

I've already stated how I solve this problem: I change how the API works internally to be compatible with Minecraft code. I know what it takes to make something like this backwards compatible because it's very obvious to me. I'm not worried about obfuscation at all because MCP does that for me. What I do "worry" about is refactoring in Minecraft by Mojang. Any major change in the minecraft source code, I have to still compensate in my API to make the old method(s) for the previous version still compatible with the new version. You didn't, all you've said is you'll be wrapping Minecraft objects with your own so mods only interact with your's to access Minecraft's, meaning your API is the only thing that is affected by changes to obfuscation. You only explained obfuscation, you never said a single thing about changes to code.
"Whether it be to the Block class, Item class, Entity class, World class, rendering, chunk loading and chunk management, tile entities, particles, whatever, any code changes Mojang makes this API has to handle before it happens to be classed as a true backwards-compatible API."

Over time, I will be making Minecraft more efficient, by providing my own obviously superior (and anyone else's) implementations of these things. Chunks? I'll make them cubic. Chunk Management? I'll put that in a separate thread to improve latency. Blocks? Static classes instead of Singletons. Entites? Same as blocks, and improve the Entity/World interaction system. World? I would improve ticking and client-to-server response times. Particles? They could easily be optimized. Explosions? I'll make those lagless. Everything else? Depends on what it is, otherwise, I'll worry about it later. Sorry if I sound rather naive and arrogant, but the optimization potential for minecraft is pretty obvious.

Quote from link_the_programmer»

You've basically summed up what half of my API does: make an abstraction layer to account for obfuscation.
The other half you missed, you basically summed up as saying what my API will not do.

There are very fundamental things you have to do for certain things to do what they do. For instance, your problem you presented me with: a complete refactoring of the rendering system in minecraft.

What is the most basic thing you need to render an OpenGl standardized model? ...? ... ok I'll tell you. It's really easy. Get a load of this: rasterize the points onto a 2D plane and apply that wire mesh with texture(s). If for some reason the rendering system were to change to, oh I don't know, the world would be refactored to use only a single 3D plane to represent the World and the actual 3D screen location, rather than two 3D planes, one as perhaps a "box" that extends infinitely* in the z axis and one plane to represent the actual World. Say I have a previous method of render(Model, x1, y1, z1, x2, y2, z2) where the first coordinates represent the World location, and that changes to render(Model, x, y, z), but my abstracted method is render(ModelWrapper, x1, y1, z1, x2, y2, z2), I would change the contents of that method to render(modelWrapper, x1, y1, z1) and I would add a method called render(ModelWrapper, x, y, z) and deprecate the other method.

Just because you change an equation fundamentally to do the same thing it did before (just in a hopefully better way) doesn't mean you can't make the old one compatible with the new because you rearranged your variables, or compressed the function, etc.

Quote from ThatAnnoyingDude»

still don't understand why everyone's still having the "how should we do lighting?" argument when cuchaz(the moon wizard) has already figured it out

Have you even read what you quoted? It's mostly "how should we load chunks" argument. Which is pretty interesting in my opinion.

Ah, Open Source. I do hope you acknowlege the amount of competition out there. Good luck.