This started as a hobby project and a way for me to learn more about graphics rendering. It is not a claim that Direct3D 12 is better than other renderers, and it is not meant to replace anyone else’s work. I had an idea I wanted to try, so I built it.
Seeing people add DLSS to different games got me thinking: could I get Minecraft rendering through Direct3D 12, as directly as Java would allow?
I first experimented with Mesa around version 0.3. That approach did not feel right for this project, and I was not eager to write all the bindings myself. I eventually switched to bgfx through LWJGL, which already fits into Minecraft’s Java ecosystem.
There were a few milestones that made the work feel real. Version 0.8.8 was the first build that actually opened the game. I was almost in tears when it worked. Version 0.9 fixed the very low frame rate, although the mod was still unstable.
The current target is Minecraft 1.21.1 with Fabric on Windows. The renderer can currently draw:
Some existing video settings are also connected to the Direct3D 12 backend, including VSync, mipmap levels, and glint strength. The F3 debug screen shows the GPU, driver, and feature level being used.
This is still experimental, so there are important gaps:
So far, my testing has been limited to a GT 1030, Ryzen 5 3600, 16 GB of RAM, and Windows 11. I would especially like to hear from people testing on other GPUs, including RTX cards. If you try it, please share your hardware and results through a GitHub issue.
GPT Codex has been my main helper for documentation and debugging. For jars prepared for release on CurseForge or Modrinth, I also use Claude Opus for an additional review. I am still responsible for what I publish. English is not my strongest area, so if you spot a confusing sentence or a documentation mistake, feedback is welcome.
I am focusing on Fabric 1.21.1 until the project is stable enough, possibly around version 1.0. A Minecraft 1.20.1 build may come later, but it is not ready yet.
I should also set expectations: I tend to ship a project once it works and may not be quick to maintain it afterward. Issues and pull requests are welcome, though replies may be slow. Please use the main branch.
If you want to explore the project or try a build, here are the links:
This is one idea among many ways to experiment with Minecraft rendering. It is simply the version I wanted to build—and mine uses bgfx.
]]>I am temporarily taking NilLoaderSDK offline while I make a number of changes to the project.
When it returns, it will no longer be called NilLoaderSDK. The project will be renamed to NilKit API.
This change follows a discussion with the maintainer of NilLoader about how the project was being presented and how easily the name and branding could cause confusion.
I want to be clear about something from the beginning: I did not intend to impersonate NilLoader, claim ownership of it, or present my project as an official component of NilLoader.
But intent does not erase the fact that the name I chose could reasonably give people that impression.
That part is on me.
When I originally chose the name NilLoaderSDK, my reasoning was simple: it was an SDK I had built for development around NilLoader.
From my perspective, the name described what the project did.
What I did not consider carefully enough was how the name would look from the outside.
Names such as “Fabric API” and “Fabric Loader” have trained Minecraft modders to associate similarly named projects with an official ecosystem. Because of that, NilLoaderSDK could easily be interpreted as the official SDK or API for NilLoader, or even as something required for NilLoader mods to work.
That was never what the project was meant to be.
I had already tried to explain in the documentation that the project was independent and that NilLoader remained a separate upstream project, but documentation does not completely solve a branding problem. Many people will see a project name, logo, or Modrinth page long before they read a README.
So I accept that I made a mistake in how I named and presented the project.
It was not intentional, but it was still my responsibility.
After discussing the issue, I proposed the name NilKit API, and the NilLoader maintainer confirmed that this name was fine.
The new name gives the project its own identity while still making sense for what it is: a collection of APIs, utilities, and development tooling intended for projects that use NilLoader.
Most importantly, it removes the implication that this is an official part of NilLoader itself.
Going forward, the distinction will be much clearer:
The original NilLoader project can be found here:
git.sleeping.town/Nil/NilLoader
Rather than changing only the repository title and leaving a mixture of old and new branding around the internet, I want to do the migration properly.
For that reason, I am temporarily making the project unavailable while I review and update everything associated with the old identity.
This includes, where applicable:
I would rather take the project offline for a short period and bring it back consistently than leave half-renamed pieces scattered across different services.
This is a pause for cleanup, not the end of the project.
The discussion was not only about the name.
Some parts of the project relied heavily on NilLoader internals through reflection and attempted to provide additional bootstrapping behavior around NilLoader’s normal machinery.
Even if those techniques can work today, internal implementation details are not a stable public API. They may change at any time, and relying on them too heavily creates unnecessary compatibility risks for both the project and its users.
I am willing to maintain compatibility when things change, but that does not mean every workaround is a good architectural decision.
So while the project is private, I will also use the opportunity to reconsider those parts instead of treating this as a cosmetic rename only.
The goal remains the same: make developing with NilLoader more convenient without trying to become NilLoader itself.
NilKit API exists because I personally encountered problems and repetitive work while developing with NilLoader.
My reaction was the same one that has started countless open-source projects: build the tool I wished I already had.
I still believe there is value in community tooling around a small, flexible project like NilLoader. Things such as development APIs, Gradle tooling, mappings support, installers, documentation, and utilities can make an ecosystem easier to approach without replacing the foundation underneath it.
I also still believe that improving and extending existing open-source software is often more useful than creating another competing implementation simply because something is difficult.
But building around someone else’s project also means being careful about where that project ends and mine begins.
That distinction should have been clearer from day one.
I also want to address this directly because it came up during the discussion.
Yes, I use AI tools as part of my development workflow.
I use them to help research ideas, review code, draft documentation, explore implementations, and speed up repetitive work. I do not consider that something that needs to be hidden.
At the same time, I am responsible for what I publish.
If an AI-generated suggestion is incorrect, if I choose a bad architecture, if documentation is misleading, or if a project decision causes problems, that responsibility belongs to me. An AI tool does not maintain the repository, make the final decision, or take responsibility for a release. I do.
That applies here as well.
For now, the GitHub and Modrinth presence associated with the project will be temporarily restricted while I complete the transition.
When the project returns, it will return as NilKit API, with a new identity and clearer separation from NilLoader.
I will also review related tooling individually rather than assuming that the same naming or branding decisions are appropriate for every project.
There is no exact reopening date yet. I want to finish the cleanup properly before making everything public again.
I want to apologize to the NilLoader maintainer and to anyone who was confused by the original name or presentation.
There was no intention to take over the project, pass my work off as official, or diminish the work of the people who created NilLoader.
I should have contacted the maintainer earlier instead of making assumptions about how close my project’s identity could be to the upstream project.
I appreciate that the concerns were raised directly, and I would rather correct the problem now than allow the confusion to continue.
NilLoaderSDK is going away as a name. NilKit API will take its place.
The idea behind the project is continuing — just with a clearer identity, a cleaner boundary, and more respect for the project it was built around.
Built and maintained by TamKungZ_.
]]>แต่ผมเจอเคสหนึ่งที่หาวิธีแก้ในเน็ตค่อนข้างยาก เลยอยากจดไว้ เผื่อมีประโยชน์กับใครบางคนที่เจอปัญหาคล้ายกัน
ปัญหาคือ TrueMoney Wallet สแกนหน้าเพื่อยืนยันตัวตนไม่ได้ บนมือถือ Huawei
ในกรณีของผมคือ Huawei Y73 ซึ่งเป็นเครื่องที่ต้องใช้ GMS ผ่าน microG ในการใช้งานบางอย่างของ Google services
หมายเหตุ: หลายคนอาจพิมพ์หรือเรียกสลับกันระหว่าง GSM/GMS แต่ในบริบทนี้ผมหมายถึงฝั่ง Google Mobile Services และ microG
ตอนใช้งาน TrueMoney Wallet แล้วต้องสแกนหน้าเพื่อยืนยันตัวตน แอปไม่สามารถผ่านขั้นตอนนี้ได้
ข้อความที่ผมเจอประมาณนี้:
ไม่สามารถทำรายการได้
กรุณาทำรายการใหม่ภายหลัง
ผมลองหาข้อมูลอยู่พักหนึ่ง แต่ไม่ค่อยเจอวิธีแก้ที่ตรงกับเคส Huawei + microG เท่าไร โดยเฉพาะเคสที่เกี่ยวกับการยืนยันตัวตนในแอปการเงิน
สุดท้ายผมสงสัยว่าอาจเกี่ยวกับ SafetyNet / Device Attestation เพราะแอปบางตัวจะตรวจสถานะอุปกรณ์ก่อนให้ใช้งานฟีเจอร์บางอย่าง
ขั้นตอนนี้เป็นสิ่งที่ผมทำบนเครื่องของผมเอง เมนูอาจต่างกันตามรุ่น Huawei, เวอร์ชันระบบ, launcher, หรือเวอร์ชันของ microG
ในเคสของผม หลังจากปิด Allow requests ของ TrueMoney ใน Device Attestation แล้ว การสแกนหน้าเพื่อยืนยันตัวตนกลับมาใช้งานได้
ผมยังไม่อยากสรุปแบบฟันธงว่า TrueMoney มีปัญหากับ SafetyNet เสมอ หรือ microG เป็นสาเหตุหลักเสมอ
แต่จากที่เจอกับเครื่องของผม ดูเหมือนว่า TrueMoney อาจติดขั้นตอนที่เกี่ยวกับการเรียก SafetyNet หรือ Device Attestation ผ่าน microG แล้วทำให้ flow การยืนยันตัวตนมีปัญหา
พอปิดไม่ให้ TrueMoney ส่ง request ตรงนี้ผ่าน microG การยืนยันตัวตนเลยผ่านได้
อย่างไรก็ตาม นี่อาจเป็นแค่ workaround เฉพาะบางเครื่อง บางเวอร์ชัน หรือบางสภาพแวดล้อมเท่านั้น
ถ้าคุณใช้แอปการเงินหรือแอปที่เกี่ยวข้องกับความปลอดภัย ควรระวังเวลาแก้ค่าเกี่ยวกับ SafetyNet, Device Attestation หรือ microG
วิธีนี้ไม่ได้แปลว่าควรปิดทุกอย่างในทุกแอป และไม่ได้รับประกันว่าจะใช้ได้กับทุกคน
ถ้าลองแล้วไม่ดีขึ้น ให้เปิดค่ากลับเหมือนเดิม แล้วลองตรวจอย่างอื่นต่อ เช่น เวอร์ชัน TrueMoney, เวอร์ชัน microG, permission ของกล้อง, network, หรือสถานะบริการของแอป
ถ้าคุณใช้ Huawei ที่พึ่งพา microG/GMS และเจอปัญหา TrueMoney Wallet สแกนหน้ายืนยันตัวตนไม่ได้ วิธีนี้อาจเป็นอีกหนึ่งทางที่น่าลอง:
microG Settings > Device Attestation > Apps using SafetyNet > TrueMoney > ปิด Allow requests
นี่เป็นแค่ประสบการณ์จากเครื่องของผม แต่ถ้ามันช่วยประหยัดเวลาคนอื่นที่กำลังหาวิธีแก้ได้บ้าง ก็น่าจะคุ้มที่จะเผยแพร่ไว้
]]>A utility SDK for NilLoader-based Minecraft mods, born out of frustration and necessity.
If you’ve ever worked with NilLoader, you already know what makes it special: it’s version-agnostic. It doesn’t tie itself to any specific version of Minecraft. As a Java agent, it simply injects your code into the game’s runtime — no strings attached.
That flexibility is genuinely powerful. But it comes with a cost.
Because NilLoader doesn’t bind to any particular Minecraft version, there’s no abstraction layer waiting for you. No event system. No registry helpers. Nothing pre-built the way Forge or Fabric hand things to you. You’re writing directly against Minecraft’s internals — and that means you’d better have a solid grasp of Java fundamentals, bytecode, and reflection before you even get started.
For seasoned modders, that’s fine. For anyone newer to the space, it’s a steep cliff.
That’s exactly why I built NilLoaderSDK.
NilLoaderSDK isn’t trying to be a new mod loader. It’s not competing with Forge or Fabric. It’s a small utility layer that sits on top of NilLoader and smooths out the rough edges — most of which I ran into myself while working on NilLoader-based projects.
Here’s what it bundles:
Reflection Helpers — Working with private fields and methods in Minecraft’s obfuscated codebase is tedious. ReflectHelper wraps the boilerplate so you’re not writing the same try-catch reflection blocks over and over. ProxyHelper extends this for dynamic proxy use cases.
Structured Logging — A consistent logging standard built around NilLoader’s NilLogger. There’s a root SDK logger (NilLoaderSDK) and a class-scoped variant (NilLoaderSDK/<ClassName>). Small thing, but it keeps logs readable across a whole project.
Entrypoint Dispatcher — NilLoader has premain and hijack phases, and coordinating those across a larger project gets messy fast. EntrypointDispatcher resolves entrypoints in a defined order — JVM properties first, then a properties file, then ServiceLoader — with built-in recursion guards so you don’t accidentally send the loader into an infinite loop.
Java NIO Networking — A full non-blocking networking layer: NioServer, NioClient, PacketCodec, PacketRegistry, and a MinecraftAutoNetworkBridge that can be wired up purely through JVM properties. Useful for mods that need to talk to external services or other game instances.
Utilities — CooldownTracker for rate-limiting logic and TargetFinder for locating entities or objects in the world.
Most of these features exist because I needed them. That’s the honest origin story.
If you’re modding old Minecraft — pre-1.7 especially — one of the biggest headaches is mappings. Modern toolchains make this almost invisible: configure Gradle, pick a mapping set, done. Back then, it was a whole ordeal.
The historical go-to was Mod Coder Pack (MCP), which handled remapping Notch’s obfuscated names to human-readable Searge mappings all the way back to Minecraft Alpha 1.1.2_01. But MCP is largely inaccessible today. The tooling has fragmented, mirrors are gone, and finding the original sources is genuinely difficult.
NilLoaderSDK includes a SimpleRemap utility — but I want to be clear about what it doesn’t do. It doesn’t ship bundled mappings, and it won’t. The reason is simple: licensing. I couldn’t reliably trace the license terms for existing mapping files, even when digging through documentation and original sources. Without clear licensing, I can’t ship them — and I’m not willing to guess.
So the approach here is intentional: developers bring their own mappings locally. You wire them into your project yourself. It’s one more manual step, but it keeps everything legally clean and gives you full control over what you’re working with.
Realistically, NilLoaderSDK isn’t going to change the Minecraft modding ecosystem. It’s a niche tool for a niche loader used by a small community of modders who prefer working close to the metal.
But if you’re in that space — if you’re building NilLoader mods and finding yourself rewriting the same reflection utilities or struggling to wire up consistent logging — this SDK might save you some time.
It’s a small thing. But small things add up.
Add the SDK to your project via Maven:
repositories {
maven { url = uri("https://repo.tamkungz.me") }
}
dependencies {
implementation("me.tamkungz.nilloadersdk:nilloadersdk:2.0.1")
}
The source is available on GitHub, licensed under LGPL-3.0-or-later.
Built by TamKungZ_ — mostly because I needed it.
]]>VLiva started as a small side experiment — something I made mostly out of frustration. I work with Live2D occasionally, and my main OS is Linux. Switching between Linux and Windows just to run VTuber software quickly became annoying.
So I looked for alternatives.
There are ways to run existing tools on Linux, but most of them involve:
None of them felt clean.
At some point I stopped searching and thought: “What if I just build something myself?”
At the beginning, I didn’t take this project seriously at all. It was more like: “let’s see if this is even possible.”
The main challenge was obvious:
This wasn’t something I could just throw together in a weekend.
Progress was slow. I spent around 5 months on the project — although realistically, I paused for more than half of that time.
Recently, I came back to the project with a different mindset.
Instead of experimenting, I wanted to actually make it work.
Surprisingly, things started to click:
And at some point, I realized:
“This is actually usable.”
Not perfect. Not polished. But real.
VLiva is a native Linux VTuber app prototype that focuses on simplicity:
That’s the core idea.
Right now, the project is still far from finished.
Things that still need work:
I’m planning to release a demo version around April to gather feedback and bug reports.
If the project reaches a stable and complete state, I may release it on Steam in the future. Pricing is undecided, but the demo will remain free.
Originally, this was just a personal tool.
But now I’m curious:
Is there actually a demand for VTubing on Linux? Are there other people dealing with the same problems?
If yes, then this project might be worth pushing further.
If not… well, at least I built something interesting.
Either way, I’ll keep going for now.
Some people suggested Inochi2D, and yes — I’ve looked into it before. Their source code is clean and their optimization approach is great.
But my main target for VLiva is Live2D support, so Inochi2D can only help as a partial reference, not a direct solution.
For some users, yes. One Linux user reported that VTube Studio + VBridger was basically plug-and-play.
That said, Linux experiences can still vary by distro and setup (Proton, drivers, etc.).
The goal is not to replace VTube Studio.
VLiva is being built as a fully native Linux alternative — no compatibility layer in between, and a simpler path for people who prefer native workflows.
I’m currently exploring that idea. It’s not confirmed yet, but compatibility with existing VBridger workflows could make adoption much easier for Linux VTubers.
]]>What I actually wanted was something that could answer a much simpler question:
“Is this file really what it claims to be?”
That sounds obvious until you start looking at media files beyond their extensions.
A file named song.mp3 isn’t necessarily a valid MP3. Some players will happily play malformed files. Others won’t. Some libraries reject them entirely. Extensions don’t tell the whole story.
That realization eventually became CodecMedia.
It started while I was building a Minecraft mod.
I wanted to play MP3 files directly through OpenAL instead of Minecraft’s built-in audio system. To do that, I needed a low-level MP3 decoder, so I used Zoom JLayer, a pure Java decoder from the early 2000s.
It worked…
…until it didn’t.
Some MP3 files decoded perfectly. Others failed completely, even though they played fine in normal media players.
Instead of assuming it was a bug, I started reading JLayer’s source code.
That was when I discovered something I had never really thought about before.
Not every MP3 file is structured the same way.
Different bitrate modes, different frame layouts, optional headers, metadata blocks—everything is described by the bytes inside the file, not by its filename.
The more I looked, the more interesting it became.
Eventually I wasn’t trying to decode MP3 anymore.
I was trying to understand how media formats actually describe themselves.
That curiosity eventually expanded beyond MP3.
WAV.
FLAC.
OGG.
AIFF.
Each format has its own signature, internal structure, metadata layout, and validation rules.
Instead of relying on file extensions, I started reading the actual binary structures directly.
That became the foundation of CodecMedia.
Today, CodecMedia focuses primarily on probing and validating media files by parsing their actual byte structure.
Rather than asking “Does this filename end with .mp3?”, it asks questions like:
Because of that, CodecMedia can identify media types from the file itself instead of trusting the extension.
Using it is straightforward.
CodecMediaEngine engine = CodecMedia.createDefault();
ProbeResult probe = engine.probe(Path.of("song.mp3"));
System.out.println(probe.mimeType());
System.out.println(probe.durationMillis());
System.out.println(probe.streams().get(0).codec());
System.out.println(probe.streams().get(0).sampleRate());
If you want to verify that a file is structurally valid before processing it, validation is equally simple.
ValidationResult validation = engine.validate(
Path.of("song.mp3"),
new ValidationOptions(true, 64L * 1024L * 1024L)
);
System.out.println(validation.valid());
System.out.println(validation.errors());
CodecMedia currently understands formats including MP3, WAV, FLAC, OGG (Vorbis and Opus), AIFF/AIFC, and several others.
CodecMedia also contains basic media conversion features.
However, conversion is not its primary goal.
There are already excellent projects like FFmpeg that provide far more complete transcoding capabilities.
CodecMedia is designed differently.
Its primary purpose is to inspect, identify, and validate media by understanding the file’s binary format directly, while providing lightweight utilities around that information.
I don’t expect CodecMedia to replace existing media frameworks.
There are plenty of mature solutions available.
The reason I built it wasn’t because those tools weren’t good enough.
I built it because I wanted to understand what happens underneath them.
Reading binary structures, interpreting headers, validating file layouts, and implementing support myself taught me far more than simply calling an external library ever could.
CodecMedia is the result of that exploration.
If it also ends up being useful to someone else, that’s a nice bonus.
Maven Central: https://central.sonatype.com/artifact/me.tamkungz.codecmedia/codecmedia
]]>