• 1

    posted a message on BAD FPS

    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.

    Posted in: Java Edition Support
  • 3

    posted a message on [Beta] The Quantum API: A Better Alternative to Forge and Bukkit

    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:


    I now have a business. I will work on Quantum API when I have time, but considering that I do not care anymore about Minecraft at all, and only consider Quantum API a hobby, and is a considerable source of income should it ever be completed, this project may be abandoned by myself without notice, so I am glad to hire any recuits, as mentioned above, but please note: this game is nothing compared to God; if you want true peace in your life, I urge you to become Catholic, examine your conscience daily, to pray for virtue, and abandon your vices; to abandon and become indifferent to all creatures which hinder your spiritual progress; and finally be at peace always, whether you are in tribulation, or in the eye of the storm. Trust me, I know by experience what True Peace is, and it is in none other than Jesus Christ Himself, and in our sanctification through grace, through the Mediatrix of all grace, the Blessed Virgin Mary, She, who shall make our hearts like Christ, by the power of the Holy Ghost, for it is through Her that God was so pleased to be born into flesh for man's sake, and so Her role in salvation is great, for it could be said that, if it were not for Her "Fiat" at the Annunciation of the Angel Gabriel, as it were, none would be saved, so thank God for The Woman, whose seed has crushed the wicked serpent! Ad maiorem Dei gloriam [AMDG]!


    That being said, the only value that Minecraft has for me and for you is to glorify God and worship Him indirectly by using our natural talents and abilities for creativity and entertainment, but within moderation. Do not let Minecraft be a source of vice, but for virtue! Do not play this game all day I say! You will do better in silence and contemplation of yourself for eight hours, than you might benefit from playing a single minute of this game! My friends, be at peace, and be free! So long as you are slave to your own will, you will never be at peace, but in doing the will of God, you will find not only solace and peace, but unlimited joy, greater and far more sustainable than any material thing on earth could please you; for we will all die one day, and what good will this earth be to us when we die?

    Do not wait for New Year's to make your resolutions; make your resolutions daily, beginning today, but without grace, you cannot change. You cannot be holy without the Catholic Church, for the Church is how we receive not just enough, but an abundance of grace, and God gives in abundance, but only to those who want it! Why work for vain things that cannot please us beyond the grave, when we can reap joy that lasts for eternity, while we are here on earth, a taste of it; in death, our full reward; and to each, our vices shall be rewarded with eternal death lest we be forgiven our offenses against so good a God Who did nothing to offend us. See the truth I speak; live it, and have your subjective proof that there is a God indeed Who is charitable to you.

    Do not be deceived either: they in Rome have lost the True Faith which distinguishes itself as Catholic. The word catholic means "universal". Who, then, calls itself Catholic, yet does not have this True and Singular Doctrine? We call it the "Novus Ordo", a new religion brought about by the confusion of the Second Vatican Council, a robber synod indeed, which would feign Catholicism and true charity for "brotherly love and affection" and false sense of divine mercy, and infected with the disease of liberalism, and Freemasonry, yet devoid of all sense of Justice and of Sacrifice and penance. The SSPX, called schismatic by those in Rome, though we recognize the Pope, we do, and a few other orders and Catholic groups, small yet precious, retain the Faith and resist all errors, be it from the Chair of Peter, or some secret heretics in high places. In Pax Christi, Andrew Porter


    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, 20141.


    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

    Posted in: WIP Mods
  • 1

    posted a message on [Beta] The Quantum API: A Better Alternative to Forge and Bukkit
    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.

    Posted in: WIP Mods
  • 5

    posted a message on [Java 8u162]Vanilla Optimizations

    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.

    Posted in: Discussion
  • 1

    posted a message on [Beta] The Quantum API: A Better Alternative to Forge and Bukkit

    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.

    Posted in: WIP Mods
  • 1

    posted a message on [Beta] The Quantum API: A Better Alternative to Forge and Bukkit

    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.

    Posted in: WIP Mods
  • 1

    posted a message on [Beta] The Quantum API: A Better Alternative to Forge and Bukkit

    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.

    Posted in: WIP Mods
  • 1

    posted a message on Cubic Chunks: Reduced lag, infinite height, and more [The #1 Suggestion Thread of all time!][Updated! 6/14]

    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.

    Posted in: Suggestions
  • 1

    posted a message on Cubic Chunks: Reduced lag, infinite height, and more [The #1 Suggestion Thread of all time!][Updated! 6/14]
    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 :P


    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.

    Posted in: Suggestions
  • 1

    posted a message on [Beta] The Quantum API: A Better Alternative to Forge and Bukkit

    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...

    Posted in: WIP Mods
  • To post a comment, please .