When they do internal modifications, but also have modders in mind, you get to have an amazing modding API basically "for free".
Pretty good for Wayland.
Anyone with experience on programming Minecraft with python? Tips?
This sounds hilarious out of the context :D
> Exclusive fullscreen mode on Windows may cause the game to crash in certain situations, especially when using multiple monitors
> Entering Exclusive fullscreen mode crashes the game on Wayland
Those, together, kinda seem like the kind of blocking bug that would usually delay a snapshot... Lets hoping it gets fixed before release lands...
One notable thing is that switching to SDL3 eliminated lag from having Discord client open while playing osu. Pretty sure this was from their devlog on YouTube.
The point of a snapshot is that it's a snapshot of current main, bugs and all, even release-blocking bugs.
In my head, the order of stability expectations are (noting that minecraft doesn't do most of these levels, nor do most projects):
1. Long-term support / extended support release
2. Release
3. Release candidate
4. Beta
5. Alpha
6. Snapshot
7. Just-merged master commit
8. Unmerged pull request from a developer on the project
9. Unmerged draft pull request from a developer on the project
10. Unmerged pull request from a stranger
11. .patch file for the source code hosted on pastebin and linked by a total stranger on a cryptocurrency related discord server
12. GitHub's servers
I would expect a fairly major bug to delay a release candidate or beta.
I would expect an absolutely critical bug to prevent merge.
I would not expect any bug which passes the CI tests and gets merged to delay a snapshot, since snapshots are just effectively a scheduled cronjob of "at this date, we cut a release of current main so people can play with it and give feedback if they want without having to figure out how to compile main themselves"
And how many current persons working on Minecraft are also Modders ?
There hasn't ever been a promise that snapshots are bug free; the expectation is rather the opposite.
You can run a standard Java Minecraft server however you like, and then you can wrap it to also work with the Bedrock using Gyser[1] which will protocol translate it on the fly. It can require some workarounds on the more restrictive bedrock clients but it does work. That will let you setup and control the server from Java which has more options available.
If you need more performance, install [fabric](https://fabricmc.net/) and then install [lithium](https://modrinth.com/mod/lithium), but do not use mods like paper or spigot or purpur as they will mess up farms.
The best thing you can do is run on the latest JVM, set your max memory as high as you can tolerate, and use ZGC. That's it.
The JVM tuning guides for minecraft will have you switching and toggling every JVM flag under the sun with extremely dubious "evidence" of the payout for the flags they switch. In some cases, they will set contradictory flags. For example, setting eden size and target pause time. The fine tuning flags disable the heuristic flags like target pause time.
KISS. ZGC has very low latency and the larger the heap you give it the less it'll slow things down (though, do keep it under 32gb. Object header compression works on heaps less than 32gb). And using the latest JVM reduces the memory needed and increases the performance in general of the JVM. Win-win.
https://github.com/itzg/docker-minecraft-server
There’s also a version for bedrock (the version that’s supported on mobile devices).
But the canonical way to do it that is both free and infinitely customizable is to host your own server. It’s pretty straightforward to do these days. However, before you do, I would suggest playing the game a bit to understand what the settings are/mean. You and your kids could play together a bit on a Realms server or a community/public server to get a feel for what you want in a custom server.
There are many ways to get it done. What worked best for us was choosing java over bedrock, renting a cheap linux vps, and writing some very simple shell scripts for starting, stopping, changing worlds, etc. Happy to talk you through anything you get stuck on!
Depends on what your goals are with the family server, Realms may not be a good fit at all. But in terms of getting kids playing together simply and quickly, it’s the easiest way to go.
As a side note, I know kids who switched to Java after years of insisting only on Bedrock and sorely regretted not making the move much sooner. This is part of growing up these days.
[0] https://modrinth.com has a bunch of mods the kids have enjoyed as well.
I have run a Docker Minecraft Server (itzg/docker-minecraft-server) for years and it's been rock solid. Best part is not having to install a lot of dependencies, the image just does it all. I think they also have a Bedrock Edition server but I never got it working right (see above).
You'd need everyone to run the Java Edition on Windows/Mac/Linux systems if you want to do it with the least amount of pain. Otherwise, people are just paying for "Realms" which are hosted servers.
_ https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski%27s_La...
SDL supports mobile; GLFW doesn't. Maybe they're unifying codebases between the platforms.
Edit: BTW SDL3 still works even on Android 4.2. I made an app using it and ImGui, without any Java.
I was, however, somewhat surprised to learn Ubuntu 24.04 didn't even ship SDL3 to begin with. Turns out SDL3 is newer than I remember. This is likely part of the explanation why SDL3 adoption is lower than expected.
No, seriously, I'm fascinated by the story. It's been over ten years. I'm happy to assume that most of the people involved are smart and good with decent intentions. I also bet there were many kinds of commercial and organisational pressures, especially because it's (a) Microsoft and (b) one of the biggest gaming acquisitions ever.
Does anyone here have any insider knowledge they could share?
Probably less than you'd think: lots of people recognise they need to leave their work behind at work and not get too emotionally invested in something they love, because at work they'll be exposed to the gut-wrenching business-decision sausage factory.
Also if for some reason you are setting the heap size high avoid going past 32 gb unless you tune object alignment. Allocating between 32 and 47 gb will result in an effectively smaller heap. Allocating more than 32 gb can result in performance penalties.
Java Minecraft is just a better toy, I'm not altogether sure it's a better game, depending on how you define game, but it's a better toy because it's so flexible. I assume Geyser can't magically donate much of that flexibility to a Bedrock client, but if the players can co-exist then that's a boon in itself.
I ended writing a demo for screen mode handling to test and document the fiddly bits.
https://github.com/bondolo/SDL3-Fullscreen-Demo
The game is Java, like Minecraft, the demo is C because I wanted to keep it as simple as possible.
osu! however, is only officially distributed on Linux via AppImage (and semi-officially via Flatpak) and bundles its own SDL for the reasons that, to my knowledge, range from the general pinning to a known stable version approach to the team backporting functionality from SDL3 to SDL2 (last one I remember is non-text-based clipboard functionality, not entirely sure though)
Probably because a lot of people feel like they need exclusive fullscreen for best performance and/or latency. But in reality borderless fullscreen is exactly the same when games use the DXGI flip model. It bypasses DWM (the compositor) to render directly to the display when only the game is visible and seamlessly allows you to switch to other windows. You can even disable Vsync and it will allow screen tearing when bypassing DWM.
You have to opt-in to it.
This was ~5 years ago, so I'm sure it's gotten better. But not that much better 8gb would cut it, either client or server side.
SDL3 added a way to tell SDL to render vertex-based geometry as well: https://wiki.libsdl.org/SDL3/SDL_RenderGeometry. Those vertexes can have 3D positions, so that counts as a 3D renderer I guess. Though of course the GPU is doing the heavy lifting; SDL is just exposing a little bit more of the GPU's functionality. It's quite useful for some 2D applications as well. I remember reading about how it could enable more efficient drawing of 2D plots or cleaner ImGUI integration, though I don't remember details.
With the way the software ecosystem works now, a lot of projects just include a copy or submodule because it's self-contained and a good candidate for it. It dynamically loads most dependencies, so it's pretty light-weight, considering. The whole static linking licensing problem is gone now, too.
For other GCs like G1 and the parallel collector, when new gen is filled up the GC pauses the application in order to run a minor collection. For G1, major collections are ran in the background until the heap fully fills up. When that happens, the GC triggers stop the world GC.
A smaller heap size would cause those pauses to be more frequent but because the heap is smaller it means that ultimately the pauses will be limited in length.
ZGC is different. Without generational mode, ZGC is collecting the entire heap every time with it, ZGC will do the young old collections.
When a collection is triggered, ZGC flips a field to indicate a collection in progress, that flip is the only pause for the application under zgc (except the case that the heap fully fills) it typically finishes in microseconds. Once collection starts, the ZGC collector threads and the in progress application are running collections. The size of the heap really doesn't change much other than the background collection could last longer (slowing down the server, but not totally stopping it from being responsive).
The payment you make with ZGC is that you do burn more CPU cycles doing collections especially while the app is running. But for a game server, that hardly matters. What matters is that the server remains responsive in a timely fashion, which ZGC enables.
Still, I’ll admit that Minecraft full screen on Mac is even worse than almost all other games.
The real reason is you want to run your game on the latest greatest WiiStation(tm). if it is written in C/C++ you sit down with a copy of their development library and change your code to fit. If it is written in java you port the jvm to the device. And I don't really know how hard that is(having never ported the jvm) but most people sort of balk at that step.
Microsoft thought it was easier/better to rewrite minecraft in C++ than port the jvm to the xbox. There was a big enough customer base attached to the original java version they did not want to discard it(backlash would be too huge and messy).
For Windows and macOS, it is just a flat "yes", since obviously in that case SDL isn't a system library.
If you're installing a game on Linux via Steam or Flatpak it isn't going to use system SDL in any case. Minecraft would probably ship a binary for use with JNI as is customary.
However, when running games outside of Steam or Flatpak, especially open source games but certainly even outside of open source, it is not uncommon to use packages that adapt the game for your OS, like AUR packages or Nixpkgs derivations. And in that case, you'll likely get system SDL. This would be the tendency for emulators, games that are open source like ioquake, and so on.
Even in a case where SDL2 is statically linked, it is still possible to attempt to load SDL3 by pointing SDL_DYNAMIC_API to a copy of sdl2-compat.
I don't know what Steam does here, but I think it doesn't matter. A large amount of the commercial games you wind up playing under Linux are running under Proton anyway at which point the SDL version makes little difference if it is used at all. So I think it is still likely to see a lot of SDL stuff silently upgraded to SDL3 on Linux, though yes there are caveats to that.
Edit: Also, I wanted to make an additional note: the Ubuntu 24.04 note is still relevant even in the face of most games shipping their own SDL3. The reason for this is simple, I think to this day a lot of people (myself included) use Ubuntu 24.04 as a sort of general Linux build platform for building binaries that work pretty much anywhere. What you wind up having to do if you want SDL3 to work there is to build it, either via your build system (not so bad to do, either via vcpkg or via CMake subprojects) or just outside the program's build process altogether. It's not asking too much, especially since SDL3 compiles very quickly relative to a lot of other software, but still, it adds some complexity that you don't get when just building with and linking to SDL2 where you can install the dev files and binaries directly with apt-get.
Edit 2: It seems Steam is using both SDL_DYNAMIC_API and sdl2-compat as of Steam Linux Runtime 4, according to Google's AI overview. Take it with a grain of salt, as I didn't feel it warranted a deep investigation, but this suggests to me you're quite likely to encounter SDL3 within Steam (for native Linux games) regardless of what the game ships.
And yeah, in the meantime, I have just been using CMake's FetchContent system for SDL3. With improvements on both CMake's end and SDL's own build system, it is quite seamless. I still wish it was a bit more elegant but I'll take "easy".
Conversely, using borderless windowed mode instead of native fullscreen on macOS adds rendering latency due to the Desktop Window Manager (DWM) compositor. The latter is 'doing it wrong' and has the lag people don't like.
A lot of the advice, for example, suggested using CMS. Which has been a terrible garbage collector almost since it was added to the JVM. When G1GC landed in 8, that was the correct GC to select for minecraft. Even the parallel collector would have been a better option than CMS in a lot of cases (sub 4gb heaps).
It was placebo. People wanted there to be SOMETHING that made things better so they reached for the billion different flags on the JVM (rather than fixing the underlying code). I've seen the same sort of mentality professionally and it's basically always been wrong.
Creating objects like crazy, range for in hot paths, not caring about data representation, chosen algorithms,....
JIT and GC were already doing heroic efforts.
Yet, it settled Notch for life, which is something to take into account in the usual question regarding which technical stack for games.
Genuine 3D support is available in SDL3 via the GPU types and functions: https://wiki.libsdl.org/SDL3/CategoryGPU
Email client and server in Lua
https://github.com/GabrielleAkers/cc-email
The whole project is a great way to get started with understanding computers, programming, and networking in an environment that appeals to the iPad generation- one that knows less about technology than its predecessors. It’s about making computers useful towards your economic and military interests with automation. You build equipment from scratch and connect it any way you please.
For this email approach:
> get 3 advanced computers and 3 ender modems then follow the instructions in the readme in the repo
> the first two computer/modems are for the auth server and email server then the third is to actually use the email client to send emails. i guess it's 2+X where X is the number of computers you want to send/receive emails on
https://www.reddit.com/r/ComputerCraft/comments/1lsl070/comm...
I like to play games like ARC Raiders using that setup. Works perfectly fine. Sure it sucks that I need Windows at all for it, but SteamOS isn't an option yet due to my 3090
- It is divided into by default 2048 regions so it will be setting region size to 4mb means with an 8gb heap, and that you’ll get an inefficient collection once you have a 2mb+ object to deal with. So there is a value to setting a bigger heap size to get a bigger region size. The max is 32mb region size then after that iirc the region count bumps. https://docs.oracle.com/en/java/javase/17/gctuning/garbage-f...
- The young gen size also something that resizes dynamically and so having a bigger max heap will let that get larger and avoid pressure and promotion of objects that would otherwise just never get promoted in the first place (stop the world to move from new to old gen). I’ve never seen this stated anywhere I can think of but believe that I’ve observed it many thousands times.
- The reason that a Full GC occurs is because the application allocates too many objects that can't be reclaimed quickly enough, this isn’t just something that is always happening in the background , I would call full gcs a tuning problem, not everyone agrees in a given org fwiw, but I’ve been able to tune them out for nearly all workloads. https://docs.oracle.com/en/java/javase/17/gctuning/garbage-f...
TLDR , as long as I have enough ram for the working set (page cache etc) I’ve had good luck cranking g1gc very high in prod and avoiding long collection times all together. You see other large deployments do similar (was big in the Cassandra space back in the day, Instagram off the top of my head was running very large heaps with g1gc before anyone else I knew of).
They almost have feature parity, but there are some small differences around the edges. There exists modded server options for enabling bedrock and java users to connect to the same server.
Beyond small toy mods id be truly shocked if anyone really was able to muster the strength to go right back to working on product after a long day of working on product, especially in game dev. With it being such a passion driven industry already, too.
It really applies to anything with a huge number of options, I remember similar things from back when I used Gentoo and the wild suggestions I'd get for what exact CC/C++ compiler options to use...
Everything you've posted is accurate but I also don't believe it contradicts what I said. I certainly simplified and I'm not suggesting G1 is a bad GC, it's one that we often use. I just think ZGC is better for the job of a game server.
G1 is an excellent GC if your application can tolerate periodic 50ms latency spikes (most applications can). My argument is that specifically for a game server, ZGC is better. That's because game servers typically have more than enough CPU horse power and added latency is detrimental to the experience. So trading off more CPU usage due to GC is a worthy tradeoff vs the added latency spikes.
That said, I'm convinced that 90% of the reason that the current mess exists is because Microsoft was convinced that most users would be migrating from Java to bedrock. And they probably would have (modding and other things aside), had the Microsoft team not decided to "fix" many aspects of redstone.
Since then there's been the constant issue of parity between the two versions, which will likely never be achieved. And 90% of the time it's because the Microsoft developers working on bedrock edition decide they know better than mojang does, so they can implement a feature in a different way, or just implement a new feature entirely.
Ugh it's a mess, and I've spent way too long thinking about it.
I’m not really a fan of the way it’s a three finger swipe sideways to leave and enter the full screen either.
I’m pretty sure I have had at some point issues where putting my cursor at the top of the window erroneously shows the menu bar within certain types of games.
Not sure if I’m remembering right, it’s been a while since I’ve tried playing games on Mac.
The menu bar is supposed to appear with the cursor at the top of the screen. I have also encountered issues where it doesn't properly hide until you bring your cursor back in order to take the cursor away again and then it hides. It's a quirk but I sort of understand why it happens and it's just a small glitch to me.
Also, GLFW reports both the scan code and the key code, just like SDL, so I'm not sure I really trust those technical details either. Usually, you want to use scan code for some things (e.g key binds) and key code for others (e.g typing), so you can't have a global switch.
Here's a bunch of GLFW questions on Microsoft's website, quite a few are Minecraft related errors: https://learn.microsoft.com/en-us/search/?terms=glfw&categor...
Also do a search for GLFW here: https://bugs.mojang.com/browse/MC
Why did notch do that?
There were next to no libraries, ecosystem, or support for Java at the time. It was such a bizarre choice.
Not to mention the JVM, GC, and all the other oddities. It was super off the beaten path to have done this.
Might as well have been Ruby or Perl.
Should I have just said no, RTFA? Which clearly doesn't state why. That better? Or say you can search yourself?
As for ChatGPT slop, I've never used that particular LLM, but some are good for bypassing ads/SEO slop while searching the internet.
You don't have to answer questions you don't know the answer to. Answering with incorrect LLM slop is bad form.
Also it's weird complaining about slop when HN is 99% slop, and has been for a long time. It was only interesting from 2008-2016 or so.
Given what it was in the very beginning versus what it very rapidly grew into, I guess it was just something that made sense at the time.
It did not start being popular :)
Seriously though, I think Java helped it get so much traction initially. Writing mods was tedious but not that difficult, and it was multi-platform for free. Nowadays I assume the vast majority are playing bedrock on consoles or PC, but at the beginning it was rather nerdy and being playable on Linux and Mac was nice for some tech-minded people.
Java allowed Minecraft to run pretty much everywhere, including as an applet (very important in its early time) and it relied (and still relies) on LWJGL which provides access to the most common stuff you'd need to make a game (OpenGL, windowing, input events, etc) - and at the time it also worked for applets too (you needed to download the LWJGL applet code but it was signed by the devs so you didn't get too many scary messages).
I used the same tech (Java+LWJGL) at the time to make a few simple demos/games and it was quite easy to make stuff - e.g. i made this[0] in a few hours using Java, LWJGL and Eclipse on the iMac i had at the time.
He used LWJGL, which probably covered a lot of his library needs.
Java has a JIT, so it's not comparable to Ruby and Perl.
Happy Snapshot Tues... Thursday? Yes, you read that right! As we've entered peak vacation season here in Sweden, snapshots might not come out on their usual schedule.
In today's snapshot we have switched the library used for window management, input and platform integration from GLFW to SDL3.
We have also added new item components for custom furnace fuels, as well as several technical changes for signs, world generation and loot tables.
Happy mining!
Represents items that Villagers can eat. Villagers will pick up items with this component in addition to items in the #villager_picks_up tag.
Represents the visibility percentage provided by an item with the appropriate minecraft:equippable component, modifying the range at which mobs are able to detect an entity
The following fields are now stored as integers rather than shorts:
The following new fields have been added:
The following fields are now stored as integers rather than shorts:
The following new fields have been added:
Matches block state and optionally block entity data and components (if present)
Fields (same as elements of minecraft:can_place_on components):
The recipes for Smokers and Blast Furnaces now use the same cooking time in their data definition as their Furnace counterparts.
The cooking time speedup is now done through the minecraft:cooking/speed_default Number Provider used by the furnace fuel components.
Performs subtraction between two arguments. Format: object with fields:
Performs division between two arguments. Format: object with fields:
Negates the input. Format: object with fields:
Performs (unclamped) linear interpolation between two arguments based on an alpha. Format: object with fields:
Rounds the input value to an integer multiple of a given function in a type-dependent direction:
Format: object with fields:
Outputs the structure bearding density. Generally summed together with the base terrain density to produce ground below, carve air around, or bury structures.
Format: no fields
Snapshots are available for Minecraft: Java Edition. To install the Snapshot, open up the Minecraft Launcher and enable snapshots in the "Installations" tab.
Testing versions can corrupt your world, so please backup and/or run them in a different folder from your main worlds.
Cross-platform server jar:
Report bugs here:
Want to give feedback?