I think the bigger problem here is that "overloading" is specifically about providing multiple functions with the same name that take different parameters. You cannot truly overload in python, partly because it is weakly typed, and mostly because function names are a key in attribute dictionaries and must be unique.
The article is showing function overriding, not overloading, which is just standard class inheritance stuff.
Minecraft comes in two flavors, Java and Bedrock. All of the mobile, console ports, and windows store versions are based on bedrock. Java is the one you download directly from the website. Bedrock isn't really about custom hosted servers, but there is a way.
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.
Apologies for hijacking an advice thread, but I'm another dad who's had to deal with this incompatibility nightmare, and I really really want to know what the hell happened within Microsoft & Mojang to end up with this mess.
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?
Minecraft started on Java, a massive mod and server community created around it. Consoles won't run JIT/JVM/Java, so the Bedrock C++ version was created. People don't want to give up the massive mod community, so OG pc players stay on Java, while console players and newer PC players go to bedrock (with some of those PC players jumping over to Java after servers or mods are discovered).
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.
Even at the time Java had some great tools and IDEs (NetBeans, Eclipse) and both computers and the JVM were fast enough for any performance issues compared to fine tuned C++ to not matter much, especially for a game like Minecraft that didn't (at the time anyway) push the CPU much.
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.
Minecraft gained popularity super fast in its early days, probably because it was a free-to-play game that worked in the browser (thanks to Java). Notch had no reputation or marketing at the time.
Different era. At the time choosing the JVM and Java language for a multiplatform project that targetted a portable runtime was not controversial at all.
> It's absolutely crazy that a game so popular - let alone any game - was originally written in Java.
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.
I remember some early posts from him about how he really liked how the debug mode made the iteration loop very short. Here's a video of him doing exactly this - it does look like a very pleasant development environment even now
There were plenty of low level libraries available then, less in the way of frameworks. It was an environment that he was used to coding in and cross-platform (in the PC world anyway).
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.
At least for libraries, Java was actually pretty good for game development at the time iirc (Admittedly, I wasn't there, so I could be misled). It was kinda your only option if you didn't want to use C++
Am I missing sarcasm here? Minecraft was developed in 2011 and Java was conceived in 1995; it was (already) an extremely mature and popular language at the time.
As a couple of others have mentioned, the original split between the original Java Edition and the now Bedrock Edition happened in 2011. This is several years prior to the 2014 acquisition of Mojang by Microsoft. So while Microsoft may have had motivations in Mojang promoting or expanding Bedrock adoption, that train had already left the station by the time Microsoft entered the picture.
I like Minecraft quite a lot and am not concerned with interoperability between Java and Bedrock... but will only play the Java Edition because of game-play differences between the two; differences in which Java Edition comes out as being materially better than Bedrock... at least from my perspective.
The developers are used to Java, and as someone who's worked with both Java and C++, Java is simply better for the kind of iterative development minecraft seems to do. From what I've seen (which admittedly isn't much more than the public facing history and the minecraft live/minecon events), there isn't really a strict roadmap and they seem to value messing with features a lot. Also, the game was only rewritten in C++ to support multiplatform ports, and bedrock isn't even the first time they did it (though, the other C++ versions, also known as legacy console, weren't handled in house). The existence of a windows version is a strange curiosity stemming from the microsoft buyout and their ability to do so since that codebase is insanely portable.
Also, mojang (not microsoft) really appreciates modders, which java edition is strictly superior for
No insider knowledge but as far as I know, bedrock is written C++ not Java. They did that for porting to other devices and consoles, as well as preformance. It also allows them to sell skins, server hosting, more micro transactions since it's more locked down. So I think it's just a thing that happened, and it has been going on for a while and if they did anything to either the Java edition or the bedrock edition then it would make a lot of people really mad.
Consoles hate having a jit vm so java is a non-starter for them.
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).
In Microsoft's defense at the time the java code base had a ton of technical debt and overtime they've essentially done a full rewrite of everything.
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.
As someone who's messed with redstone on both, Bedrock is uniquely infuriating because it adds some really cool things (being able to move entity blocks like chests and furnaces comes to mind) while completely destroying the groundwork of even moderately advanced redstone. The most visible is the timing for certain things becoming nondeterministic, and while technically a bug originally, quasi-connectivity is extremely useful
> Microsoft thought it was easier/better to rewrite minecraft in C++ than port the jvm to the xbox.
I don’t think that’s quite right. IIRC, the mobile iOS version was released before the Xbox one and neither were developed by Microsoft. I think eventually it’s the mobile version that became Bedrock and replaced the older console version, which became a dead end.
The mobile version (released in 2011) could not be in Java, otherwise it could not have been sold on iOS. So at least initially it was more a business decision about which platforms to target than a technical decision to do away with Java.
All this happened years before Microsoft bought Mojang.
Unless I've got the product genealogy wrong, the rewrite predated Microsoft. The mobile version was also C++ based, and I think it is the distant ancestor to bedrock/windows/console editions.
I know this is probably not as easy as it is in my head, but doesn't xbox have a .net runtime? It would completely take away the portability aspect, but if the original 360 port was handled in house I could totally see them using that weird Java on .net thing in at least some capacity
Bedrock has much better performance so it was used for consoles, but there were already hundreds of thousands of mods for Java edition, thus the split.
And also it has worse performance than Java if you just install a basic optimization modpack like Adrenaline on Java, which many players do. There's effectively ~zero reason to use Bedrock if you're on PC.
Geyser sounds very interesting especially if you know some or all players wouldn't be willing or perhaps able to play Java Minecraft and so they have to run Bedrock, but some would play Java and they'd enjoy being together.
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.
Aside from being more flexible they are mostly the same game. The original excuse for bedrock was that Java was slow and a native game would render much better, it was also easier to put shaders in a a native codebase. But Java edition is pretty performant nowadays and computers also got much more stronger than the game became heavier
As far as I can remember the origins of Bedrock are the original console releases which couldn't ship a JVM. So a whole new codebase was developed, and ultimately it was more performant as it had to run on 7th gen consoles.
Console releases were done by a different studio originally, 4J Studios. Bedrock spawned from the mobile ports, and eventually replaced the console editions and had different features.
Java edition still horribly underperforms. It’s mostly single-threaded and even if they’ve rewritten the lighting engine a few times (those decade old black-block bugs disappeared), the Sodium family of mods show you how much it can be improved.
I do a lot of floppy imaging and some of my work on it has previously be discussed here[1]. I do not understand where they got the idea of "there are a number of disks that the Greaseweazle struggles to capture, namely the Apple formatted disks. If you have these disks in your collection, you may need to use an Applesauce controller."
The Applesauce is a macOS exclusive tool that has a contingent of dedicated users. While I have not imaged a wide sample set of Apple II and 800k Mac disks specifically, from my current experience the Greaseweazle is plenty capable of reading them. I would speculate the author was trying to use an included diskdef(a flux to binary decoding definition) for an incompatible disk. The Zone Bit Recording[2] Apple drives use is irrelevant when you increase the sample rate of the controller to accomplish the same thing. Similarly C64 disk drives are also ZBR but change the clock rate instead of media speed. So do not think that this means you need multiple drives and controllers when getting into floppy imaging, you can use standard PC drives with a Greaseweazle to read and write Apple II and Mac disks as well as almost anything else.
I have opened an issue on their github page for this site to seek clarification on this.
I received a response stating something similar on the git repo. It is still incorrect to blame the controller, and I suggested instead to provide some compatible drive models to use instead like they already do in the more generic sections of the article. It should even be possible to to use the Mac drives with the Greaseweazle with an adapter because the 800k drives from the Apple computers are just Sony drives with an optional eject motor installed.
Unlike the Apple II they do not have a custom Apple PCB. It's possible Apple requested some tweaks when ordering from Sony but I don't think they are all that special. So it should be entirely possible to read the disks with other drives. Based on the information in the page you linked stating any 720k drive is compatible, I suspect the higher read rate may be a vestigial feature that Sony over spec'ed during the introduction and standardization of the 3.5in disk.
This section is disregarding a key lore element, the inhabitants of the grid are programs. Killing a process in this context more likely has an interpretation of an attempt to stop an individual such as the villain Clu. I would say an alternative explanation is is more story based, with Kevin Flynn trying to stop Clu from the outside world but being unable to and instead taking the last resort of entering the grid when he knows it would be dangerous.
That's a good idea, but remember that, up until CLU's outright betrayal, Kevin had no reason to be concerned, and after it, he had no way back into meat space to run those commands.
Also -- unrelated, but a nitpick of the article -- Kevin was using the laser to come and go from the grid for a while before he got stuck there. The laser would have been pretty well-tested by the time he made/edited the last will and testament, so the article's explanation that it was his first use of the tech doesn't make sense. (He could have just spontaneously decided to update it though, which isn't too far fetched)
> can't afford to pay one for whatever business I have
At small scales what "art" does your business need? If you can't afford to hire an artist (which is completely fine, I couldn't for my business!) do you really need the art or are you trying to make your "brand" look more polished than it actually is? Leverage your small scale while you can because there isn't as much of an expectation for polish.
And no, a band poster doesn't have to be a labor of love. But it also doesn't have to be some big showy art either. If I saw a small band with a clearly AI generated poster it would make me question the sources for their music as well.
I've been editing on linux with resolve since the launch of the BMPCC4K in 2018, were you trying to import MP4 footage? BMD can't be bothered to pay for the AAC audio codec for linux users even if they buy studio. So if you pay for studio you can read the h264 video stream but not the AAC audio. I end up converting everything to MOVs with pcm_le16 audio as a workaround.
The ALSA issues are beyond aggravating at this point. You do not want to actually run ALSA directly, you need it to connect to pulseaudio on 24.04. But I still have never been able to record audio within resolve. I've had mixed luck on newer wayland+pipewire setups with having to install the bridge packages to connect the different backends. Linux audio is cursed on its own so I don't fully blame BMD.
I exclusively run Kubuntu and have been using makeresolvedeb[1] for installing resolve and it has been pretty good.
> Some games are designed around content and "extraction". Many are not.
While I think the parent post leaves a lot of open ended questions, I think they are spot on about the tightness of design in games.
In many open world RPGs, or something like GTA, you cannot open every door in a city.
In street fighter you can't take a break to talk to your opponent.
In art games like Journey you cannot deviate from the path.
Games are a limited form of entertainment due to technical and resource restrictions, and they always will be. Even something as open ended and basic as minecraft has to have limits to the design, you wouldn't want the player to be able to collect every blade of grass off of a block just because you could add that. You have to find the balance between engaging elements and world building.
Having a LLM backed farmer in an RPG that could go into detail on how their crops didn't grow as well last season because it didn't rain as much seems good on paper for world building. But it is just going to devalue the human curated content around it as the player has to find what does and does not advance their goals in the limited time they have to play. And if you have some reward for talking to random NPCs players will just spam the next button until it's over to optimize their fun. All games have to hold back from adding more so that the important parts stand out.
> Yes - some things go out of fashion for a while, but trends almost always cycle back.
Exactly, this is even supported by Nintendo's own services offering emulation of their older systems. There is clearly demand for the ability to older games.
Capitulation to an "inevitable" fate of download only games is just taking the easy way out by not sticking to your own core values. I have personally pre-ordered a Switch 2, but I will not being purchasing any online only cartridges or download only software.
We haven't had the watershed moment that brings it into focus for gamers at large yet, The Crew was close. But Nintendo has kept the download servers going for all of their systems which has provided a false sense of security. Once those start being shut down maybe we'll see some actual response. Though with the introduction of Gamecube emulation on the Switch 2, they are only a small step away from emulating the Wii and giving people another scapegoat for their lazy acceptance of lack of ownership.
I have a project that uses a proprietary SDK for decoding raw video. I output the decoded data as pure RGBA in a way FFMpeg can read through a pipe to re-encode the video to a standard codec. FFMpeg can't include the Non-Free SDK in their source, and it would be wildly impracticable to store the pure RGBA in a file. So pipes are the only way to do it, there are valid reasons to use high throughput pipes.
What percentage of CPU time is used by the pipe in this scenario? If pipes were 10x faster, would you really notice any difference in wall-clock-time or overall-cpu-usage, while this decoding SDK is generating the raw data and ffmpeg is processing it? Are these video processing steps anywhere near memory copy speeds?
You have the dependency either way, but if you use the library you can have one big executable with no external dependencies and it can actually be fast.
If there wasn't a problem to solve they wouldn't have said anything. If you want something different you have to do something different.
It looks like FFmpeg does support reading from sockets natively[1], I didn't know that. That might be a better solution in this case, I'll have to look into some C code for writing my output to a socket to try that some time.
At some point, I had a similar issue (though not related to licensing), and it turned out it was faster to do a high-bitrate H.264-encode of the stream before sending it over the FFmpeg socket than sending the raw RGBA data, even over localhost… (There was some minimal quality loss, of course, but it was completely irrelevant in the big picture.)
No, because I had hardware H.264 encoder support. :-) (The decoding in FFmpeg on the other side was still software. But it was seemingly much cheaper to do a H.264 software decode.)
The article is showing function overriding, not overloading, which is just standard class inheritance stuff.