One thing it taught me was that sometimes the corrections would be in next month's edition, so I had that long to figure out for myself why the program didn't work as stated.
Most of us in electronics in the 1970s in the UK had physics degrees I think. And when I moved sideways into software much later the physics background was eminently useful when modelling machinery and physical processes.
But I too have met engineers with music and also medical backgrounds. But that's all more than half a century ago, it seems that employers expect much more narrowly focussed qualifications these days.
A buddhist would tell you that a person is not an object, but a process, that consists of 5 aggregates, of which only one is the body. So the objection here is to the use of the word 'you'.
it’s a loose usage. necessary but not sufficient type of thing. if all your DNA instantly disintegrated, the process ends quickly, you are not you in many senses of the word. to preserve the artifact of DNA is to ensure (some of) the process continues uninterrupted; at least a few major failure modes of “the end of you” are mitigated. but gotta love me some Buddhist pedantry y’all can spar with the best
Then I will entertain you with another Buddhist objection - there is also no "end" since the conditioned "you" exists in the beginningless, endless cycle of samsara, while the unconditioned you (Nibbana) is unborn, unbecome, unmade, unfabricated.
Well it did used to run on early Raspis. Maybe you don't realise how much less efficient it's gotten? It used to run fine in 256MB with small render distance.
So how did they break that?
* run both server and client when in singleplayer - doubles memory use
* turn byte block IDs into object pointers - octuples memory use for blocks
* make all game content into JSON object trees with huge amounts of indirection - adds about a GB of objects deserialized at startup that used to be simple if/then ladders
* add a whole bunch of code to handle these object trees, don't know how much this adds but probably 100MB of code when you include the raw class files through to the JIT-optimized assembly.
Are you referring to Minecraft Pi Edition that came with Raspberry Pi OS back in the day? The one made in C++ instead of the original Java edition?
> run both server and client when in singleplayer - doubles memory use
When did this change? It's been like that for as long as I can remember. It's actually a very common thing for games to do because it requires less code. Also it doesn't actually double memory use - game content can be shared, textures/meshes/audio is only on the client, etc. The chunk and entity data would need to be duplicated but they should be smaller.
> Chunk data was traditionally the biggest part of Minecraft's memory use until they added a bunch more garbage.
But that's only really because it is extremely light on assets that are typically large in other games.
I'm a bit indifferent about this. Obviously they made a lot of decisions that aren't good for performance but it's a tradeoff. Notch was most productive working in Java so he could pump out updates quicker, and it helped with modding even though builds were obfuscated. NBT helped maintain backwards compatibility of worlds and probably helped with modding too. If they had done things differently then Minecraft may not have been the huge success that it is.
Yes, Minecraft doesn't have a ton of assets and it does have a lot of block data, so they should have optimized the block data and not worried about the rest. Instead they pessimized the block data.
They even managed to pessimize the assets. They did this by, during startup, pre-converting every possible rendering state of every block in the game into a static 3D model made out of Java objects (Vertex, Face, etc). This wastes about a GB of RAM.
Before Minecraft 1.8, blocks were rendered by running block-specific code for each block to render it in the needed state. One function would append a ladder to a vertex buffer, another function would append a cube to a vertex buffer, another one for stairs, etc. Since the same code block would render any material variant and direction variant of stairs, this didn't use excessive memory.
I know that in 1.8, the biggest single waste of models was redstone dust, because it comes in 16 power levels and approximately 3^4 side connection states (connected, not connected, and connected up the side of a block, but not all combinations are possible) which is over 1000 unique models. Not sure if this is still the case.
> Yes, Minecraft doesn't have a ton of assets and it does have a lot of block data, so they should have optimized the block data and not worried about the rest. Instead they pessimized the block data.
Inefficient but surely beneficial to modding.
> pre-converting every possible rendering state of every block in the game into a static 3D model made out of Java objects (Vertex, Face, etc). This wastes about a GB of RAM.
Alternatively, these are the game's assets, so it isn't a waste. Running the code to generate blocks all the time wouldn't be ideal so caching makes sense but I don't know why they wouldn't lazily populate it.
A few weeks ago I needed a computer to be a Debian server for some at-home simple Web dev / learning stuff. I bought an HP Prodesk 400 G3 SFF PC with i5-6500, 8GB RAM and a 256GB off a popular auction site for £44. It'll do. I might upgrade to 16GB. An additional 8GB stick costs £19.
Good work. I bought an AMD Ryzen 3 3100 for €35 with shipping. A Radeon W5500 would set me back €150 at the moment. 16 GiB of RAM another €90. And that's on a relatively cheap site in my country.
I daresay you could find the odd example, as for any grid in a stressed situation, but it's not like we turn to each other every week in the dark and say "Oh, it must be half time at the Manchester United match".
The state of search has been dire for quite some time.
- in 2026.
reply