Sapphic Math

A Glitter Teto render I made.

This sketch is incredible. Perfect moment to capture. 10/10 for the artist.

Link to post

I believe I have talked about Java's Project Panama before, but as a quick summery: it allows Java to call and interface with native libraries in a much nicer way than past methods (JNI, Java Native Interface, for example). Combing this with tooling like Jextract, which can read C headers and turn them into basic Classes full of basic helper methods, makes Panama extremely nice to work with as a developer. But with this stated, Panama does not require C, instead it needs programming languages that are compatible with the C ABI; which Rust is! As well, to accelerate workflows, there is a Rust "crate" (package) for auto-magically building C or C++ headers from FFI (Foreign Function Interface) compatible Rust structs/functions (called cbindgen); which works out of the box with Jextract.

Some examples of generated code. Image 1 is Jextract, image 2 is cbindgen

All of this comes together to this, Carbonated Cubes. Which is a Minecraft Mod idea I have had for a while - hyper optimized Multiblock structures that sidestep the standard MC world. Currently it is not much, but it shows a functioning prototype of Java <--> Rust communications! It is a bit of mess currently, but there is a State struct in Rust that will hold the state of a World, found here. Then, there is a FFI compatible wrapper around State called FFIState, this outlines the basic methods of communication to the State from outside of Rust.

Finally, the rising Rust meets the falling Java here (which references classes that only exists when the project's build script is ran). And the StateWrapper is a very simple wrapper around the FFIState, which translates the more esoteric Panama calls into basic Java Methods for easy use! But the abstract is a very comfortable place with no sharp edges - so this is why there are ad-hoc tests located here to test the Rust <--> Java communications.

TLDR:

Block placing is relativity simple, whenever a block is placed, the level checks if the block is registered with "Mappings" (a singleton that keeps track of all Java <--> Rust data). If so, adds the block, or removes the block if it was cleared or replaced. However, this system only tracks additions and removals during run time, meaning if the world was restarted, all data would be lost! Which is... not optimal.

So, what I could do instead is a system of where Rust saves all blocks in the fake Rust world (called the Pseudo World), and write it to a file... which well, works. But if there are any edits to the file out of gameplay, may cause breaks; or if the system goofs up and doesn't add a block to the pseudo world, could cause desyncs. So instead, I haven taken the much saner approach: PARSE THE WHOLE WORLD DIRECTORY. Is this good? Likely not, but it works! Also, the whole system is parallel and multi-threaded. Meaning the only limit is IO speeds and CPU.

Also, testing on a simulated well played world (Hermitcraft season 9; with a few popular building blocks registered as casings) has a max extra loading time of ~25 seconds. And on a smaller, simpler world: only ~25 ms Ignore that middle line for now lol

So with basic loading/parsing, now I needed to implement multiblocks and their checking. I won't go too in detail - since that could be its own whole thing. But there are 4 "types" of multiblocks: Static, Expandable, Upgradable, and Rearrangable; and each type defines how the physical shape is. Currently though, only Static is implemented, and the rest is planned, but not anywhere near done.

As for how one registers a multiblock, it may get changed later; but currently: first it is registered in a normal MC registry, along with stating what its main casing is. This will then automatically register a block/item for the controller. And then attempts to locate a JSON. Within the JSON, is a bunch of fields, each of them are: Processes Type, what recipe type the multiblock will do (once recipes are added), Multiblock Type, the shape of the multibloc (IE: Static,). Axis is unimplemented for now, and may get cut later. But, structure and mapping are the most important ones.

Structure defines the real multiblock, which is an array of array of strings. And mappings defines character -> resource location mappings. Currently Either, and ID are implemented; Either can be either block one or block two, and ID is just a basic ID. Importantly, there are a few predefined characters: "c" is the the controller (there can only be one "c"). "#" (not shown) is just the casing. "@" is an either of casing or the controller. And finally, "_" which represents empty/any space The above JSON produces a multiblock that looks like this!

As well, due to how the system is implemented: Multiblocks sharing walls or ports is explicitly supported, each of those controllers (textured blocks) are valid!

Now for the last (partly) implemented part: data saving. Each multiblock and hatchs (unimplemented) will have a data to save. And they could be saved via Block Entities, but the whole system is meant to be detached from Java, and able to tick outside of normal chunk loading, so that wont work. Instead, a much saner thought I had was to just, write all the data as NBT, into the region folder! This will store: hatch items and multiblock progress. As well as any other random bits and bobs of data. Currently the file holds no data, but it shows promises!

I believe I have talked about Java's Project Panama before, but as a quick summery: it allows Java to call and interface with native libraries in a much nicer way than past methods (JNI, Java Native Interface, for example). Combing this with tooling like Jextract, which can read C headers and turn them into basic Classes full of basic helper methods, makes Panama extremely nice to work with as a developer. But with this stated, Panama does not require C, instead it needs programming languages that are compatible with the C ABI; which Rust is! As well, to accelerate workflows, there is a Rust "crate" (package) for auto-magically building C or C++ headers from FFI (Foreign Function Interface) compatible Rust structs/functions (called cbindgen); which works out of the box with Jextract.

Some examples of generated code. Image 1 is Jextract, image 2 is cbindgen

All of this comes together to this, Carbonated Cubes. Which is a Minecraft Mod idea I have had for a while - hyper optimized Multiblock structures that sidestep the standard MC world. Currently it is not much, but it shows a functioning prototype of Java <--> Rust communications! It is a bit of mess currently, but there is a State struct in Rust that will hold the state of a World, found here. Then, there is a FFI compatible wrapper around State called FFIState, this outlines the basic methods of communication to the State from outside of Rust.

Finally, the rising Rust meets the falling Java here (which references classes that only exists when the project's build script is ran). And the StateWrapper is a very simple wrapper around the FFIState, which translates the more esoteric Panama calls into basic Java Methods for easy use! But the abstract is a very comfortable place with no sharp edges - so this is why there are ad-hoc tests located here to test the Rust <--> Java communications.

TLDR:

Block placing is relativity simple, whenever a block is placed, the level checks if the block is registered with "Mappings" (a singleton that keeps track of all Java <--> Rust data). If so, adds the block, or removes the block if it was cleared or replaced. However, this system only tracks additions and removals during run time, meaning if the world was restarted, all data would be lost! Which is... not optimal.

So, what I could do instead is a system of where Rust saves all blocks in the fake Rust world (called the Pseudo World), and write it to a file... which well, works. But if there are any edits to the file out of gameplay, may cause breaks; or if the system goofs up and doesn't add a block to the pseudo world, could cause desyncs. So instead, I haven taken the much saner approach: PARSE THE WHOLE WORLD DIRECTORY. Is this good? Likely not, but it works! Also, the whole system is parallel and multi-threaded. Meaning the only limit is IO speeds and CPU.

Also, testing on a simulated well played world (Hermitcraft season 9; with a few popular building blocks registered as casings) has a max extra loading time of ~25 seconds. And on a smaller, simpler world: only ~25 ms Ignore that middle line for now lol

So with basic loading/parsing, now I needed to implement multiblocks and their checking. I won't go too in detail - since that could be its own whole thing. But there are 4 "types" of multiblocks: Static, Expandable, Upgradable, and Rearrangable; and each type defines how the physical shape is. Currently though, only Static is implemented, and the rest is planned, but not anywhere near done.

As for how one registers a multiblock, it may get changed later; but currently: first it is registered in a normal MC registry, along with stating what its main casing is. This will then automatically register a block/item for the controller. And then attempts to locate a JSON. Within the JSON, is a bunch of fields, each of them are: Processes Type, what recipe type the multiblock will do (once recipes are added), Multiblock Type, the shape of the multibloc (IE: Static,). Axis is unimplemented for now, and may get cut later. But, structure and mapping are the most important ones.

Structure defines the real multiblock, which is an array of array of strings. And mappings defines character -> resource location mappings. Currently Either, and ID are implemented; Either can be either block one or block two, and ID is just a basic ID. Importantly, there are a few predefined characters: "c" is the the controller (there can only be one "c"). "#" (not shown) is just the casing. "@" is an either of casing or the controller. And finally, "_" which represents empty/any space The above JSON produces a multiblock that looks like this!

As well, due to how the system is implemented: Multiblocks sharing walls or ports is explicitly supported, each of those controllers (textured blocks) are valid!

Now for the last (partly) implemented part: data saving. Each multiblock and hatchs (unimplemented) will have a data to save. And they could be saved via Block Entities, but the whole system is meant to be detached from Java, and able to tick outside of normal chunk loading, so that wont work. Instead, a much saner thought I had was to just, write all the data as NBT, into the region folder! This will store: hatch items and multiblock progress. As well as any other random bits and bobs of data. Currently the file holds no data, but it shows promises!

or the concept of a pride flag is considered to be inappropriate for 13 year olds.

happy pride 2026. here's a pride flag for when corporate interests of a site run by dogshit transphobes, handwringing pearlclutchers, and "powerless" "allies" tell you that pride and your gender is no one else's fucking business: