Forem: not a pro

The Crazy Way a Dev Avoided Copyright on Leaked Claude Code

not a pro — Tue, 31 Mar 2026 16:46:51 +0000

On March 31, Anthropic’s AI coding tool “Claude Code” had its entire source code suddenly leaked online.

The cause? A .map (sourcemap) file included in the npm package — the very file every developer knows all too well.

When built with Bun, the sourcemap generated by default contained the complete original TypeScript source code embedded inside it. This allowed the full source to be extracted via the sourcemap. But the real problem starts here.

Leak → Immediate Backup → DMCA Blitz

The first person to report the leak was Fried_rice.

The publicly shared ZIP file (src.zip) contained Claude Code’s full architecture, system prompts, tool implementations, unreleased feature flags (such as KAIROS, BUDDY, ULTRAPLAN, etc.), and even Undercover Mode.

realsigridjin quickly created a backup on GitHub.

However, Anthropic reacted immediately, firing off DMCA (copyright takedown) notices one after another. Repositories hosting the original code were taken down in rapid succession.

“Copyright infringement — of course they’d do that.” Up to this point, it was a standard story.

Then Came the “God-Tier Evasion”

What realsigridjin did next was on a completely different level.

He completely rewrote the same repository in Python and republished it.

Original: TypeScript (Anthropic’s official code itself)
New: Python (automatically converted and reimplemented using Codex / oh-my-codex)

The new repository (instructkr/claude-code or related clawd-code repos) has nearly identical functionality, yet can claim “this is not copyright infringement.”

What’s more, the rewrite was completed in just a few hours. It’s said that he simply handed the task to an AI agent with the instruction: “Reimplement Claude Code in Python.”

As Gergely Orosz (@gergelyorosz) accurately pointed out:

“Copyright does not protect derived works. Rewriting TypeScript code in Python means copyright no longer applies.”

(Copyright does not protect “derived works.” If you rewrite TypeScript code in Python, copyright no longer applies.)

Why Does This Bypass Copyright Infringement?

The fundamental principle of copyright law is that it protects “expression,” but not “ideas, functions, or algorithms.”

Rewriting the exact same logic from scratch in a different language = “different expression”
Even if an AI performed the automatic conversion, one can argue that “a human reviewed the specification and reimplemented it”

In other words, “translation versions” or “ports to another language” sit smack in the middle of a legal gray zone, but in practice, DMCA takedowns become extremely difficult to enforce.

In fact, this Python version is still alive and its star count is skyrocketing.

For Anthropic, this is the worst-case scenario:

Even if they DMCA the original, the “Python version” remains
Taking it down would spark a huge debate: “Are you trying to use copyright to control even AI-generated derivative works?”
It threatens the very value of the Claude/Code tools they are building

What This Means: “The Collapse of Copyright in the AI Era”

This incident made one thing crystal clear: closed-source code can no longer be protected.

Using AI agents, a 57MB TypeScript codebase can be converted to Python in just a few hours
Simply changing the language allows one to claim “this is not copyright infringement”
Developers around the world have already learned the flow: “leak → immediate rewrite → publish”

Hiding source code is rapidly becoming meaningless.

No matter how much Anthropic emphasizes “safety first,” we have entered an era where one npm publish mistake can expose the entire source, and AI can instantly generate a “legal” clone.

In Conclusion

@realsigridjin’s move was truly “way too wild.”

Legally on the edge, ethically highly aggressive, and technically brilliant.

The perfect punchline? He reportedly did it because his girlfriend was worried that “Anthropic might sue us.”

This is reality in 2026.

The Claude Code leak wasn’t just an accident — it may have been the moment AI began smashing the old rules of copyright.

X: @LostMyCode
GitHub: https://github.com/LostMyCode

Claude Code Turned a 2003 Windows Game into a Browser Game

not a pro — Mon, 30 Mar 2026 14:16:30 +0000

Have you ever played an online PC game?

These days, cross-platform support is everywhere, and you can jump into games on pretty much any device without a second thought.

But just a few years ago, if you heard “PC game,” it almost always meant Windows only.

You’d wait through a painfully long download and installation, then finally launch the game — a ritual many of us remember all too well.

This time, I took GunZ: The Duel, a 2003 Windows-exclusive online TPS, and brought it fully into the browser using WebAssembly and WebGL.

No download. No installation.

All you do is open the page in Google Chrome.

Maybe it’s just me, but isn’t it kind of magical to play a game that once took hours of setup… by simply clicking a link?

Also: I barely touched the original source code. About 99% of the new code was written by AI.

In this article I want to share both the technical journey of porting GunZ to the browser, and a real-world example of something that was previously considered impossible… until AI coding assistants changed the game.

GunZ: The Duel — Now a Full Web Game

GunZ was developed by Korea’s MAIET Entertainment. Its signature gameplay — wall-running, aerial combos, switching between sword and gun mid-air — made it incredibly unique. I was obsessed with it back in the day.

In 2007 the entire source code (C++ client + server) leaked, and the community has been maintaining it ever since.

This game is over 20 years old… and no one had ever managed to make it run in a browser — until now.

Whiplash GunZ: https://gunz.sigr.io/

Just open the link and play. No Windows required. It works on Linux, macOS, iPhone, Android — pretty much anything (though playing seriously on mobile is… challenging 😂).

This isn’t a “kinda works” or “looks similar” demo.

It’s the complete original game, running exactly as it did in 2003.

In this post I’ll cover:

How it was actually achieved
Why I decided to do this now, after 20 years
All the previous failed attempts

Previous failures and the road to full browser port

Past attempts that failed

This isn’t my first try at browser GunZ.

A few years ago I attempted to rebuild it from scratch in JavaScript + Three.js:

https://github.com/LostMyCode/three-gunz

I got map rendering working, but re-implementing the entire game engine was overwhelming. The project died quietly (the repo is still there if you’re curious).

The WebAssembly Route

GunZ is almost entirely written in C++.

We all know you can compile C++ to WebAssembly with Emscripten, so in theory it should be easy, right?

Wrong.

GunZ is extremely Windows-dependent. It calls Windows-specific APIs for rendering, audio, input — everything. The rendering engine uses Direct3D 9 directly.

Emscripten can’t magically turn Direct3D calls into something the browser understands.

So any serious port meant rewriting thousands of lines of rendering code to use WebGL instead.

No way I was doing that by hand.

That’s why the project stayed in the “theoretically possible but I’ll die before finishing” category for years.

Then the AI era arrived

I kept thinking: “The C++ source exists… if only I could just use it.”

I couldn’t do the port myself. But what if AI wrote the hard parts for me?

Once powerful coding agents became reliable, I finally decided to try.

I used two tools:

Google Antigravity (AI Pro plan — ¥2,900/month)
Claude Code (Max 5x plan — $100)

I started with Google Antigravity.

The AI handled:

Analyzing the massive C++ codebase
Finding every Windows API dependency
Abstracting Direct3D calls
Fixing the build system for Emscripten

Watching an AI understand and refactor a huge legacy codebase in hours instead of days was honestly mind-blowing. One evening I went out drinking with friends… came back and the work was done. First time I ever felt that rush.

The Google plan was amazing — until Google suddenly tightened the rate limits. A project this size would hit weekly quotas instantly.

So I switched to Claude Code (the $100 Max 5x plan).

I was scared the $100 tier would still hit limits — but it didn’t. Quota barely moved. Bugs that blocked me for a week in Antigravity were fixed in hours.

How we removed the Windows dependency — real-time Direct3D → WebGL translation

The biggest blocker was the rendering engine — tens of thousands of lines all calling Direct3D 9 directly.

Rewriting every call was insane.

Building a full transpiler was also unrealistic.

So I did this instead:

“What if the game keeps calling Direct3D exactly as before, and I just translate every command to WebGL on the fly?”

That’s exactly what I built.

https://github.com/LostMyCode/d3d9-webgl

I inserted a translation layer between the game and the graphics API.

The original game code was left 100% untouched.

Approach	What It Means	Problem
Manually rewrite game code	Change every D3D9 call to WebGL	Tens of thousands of changes, impossible to maintain
Build a transpiler	Auto-convert D3D9 → WebGL	Semantic differences make it impossible
Translation layer	D3D9-compatible API that outputs WebGL	Only have to implement the wrapper

This approach let me remove the biggest Windows dependency without touching the original game.

(Again, mostly done by Antigravity and Claude — these AIs are terrifyingly good.)

I wrote a separate deep-dive on the D3D9→WebGL wrapper if you’re interested:

not a pro

Mar 5

d3d9-webgl — Run Legacy D3D9 Code in the Browser Without Rewriting It

#webassembly #webdev #webgl #gamedev

Comments

3 min read

Everything Else I Had to Port

Rendering was the hardest part, but it wasn’t the only one.

Network: The Server Runs Inside the Browser

This part surprises everyone.

I also compiled the original C++ server to WebAssembly and run it as a Web Worker in the same browser tab.

Instead of real network packets, the client and server talk through postMessage.

Everything runs locally in one tab.

Player data, stats, etc. are saved with SQLite + IDBFS (IndexedDB), so your progress survives tab closes — a completely serverless game server.

Of course, you can still connect to a real server via WebSocket for online play with other people.

Sound: FMOD → Web Audio API (1,260 lines)

The original game used FMOD. I replaced it entirely with the Web Audio API, re-implementing 3D spatial audio (PannerNode), BGM streaming, distance culling, and everything else the game needed.

Input: Turning Browser Events into Win32 Messages

I convert keyboard/mouse browser events into the exact Win32 messages (WM_KEYDOWN, WM_MOUSEMOVE, WM_CHAR, etc.) the original engine expects.

Pointer Lock API for mouse capture and an HTML <input> overlay for login text input were also required.

Filesystem & Asset Loading: 2-Stage + Cache API

GunZ assets are stored in custom .mrs archives.

I load the 7 critical files first, then stream the rest (weapons, maps, etc.) in the background.

Cache API ensures second visits are instant.

Game Data Optimization (This Took Forever)

Since everything has to come over the network, I spent weeks shrinking the data.

I created version after version (default → v2 → … → v10) until load times were acceptable.

The biggest win? Converting all sound effects from WAV to Opus.

44.3 MB → 5.30 MB — an 88% reduction.

Aspect	WAV (Waveform Audio)	Opus
Compression	None (Linear PCM)	Lossy (extremely efficient)
Sound Quality	Perfect (raw)	Excellent (especially at low bitrates)
File Size	Huge	Tiny
Latency	Zero	Very low (5–26 ms)
Browser Compatibility	Universal	Modern browsers & mobile
License	Completely free	Royalty-free

Result? You can start playing in under 10 seconds.

All assets are served from S3 + CloudFront, so they load fast from anywhere in the world.

Final Thoughts

Sometimes you just have to wait for the right time

Waiting for the right moment was key.

I knew almost nothing about WebGL or Direct3D. If I had tried this five years ago, I would have given up.

But in the AI era, it finally became possible.

Thank you, Antigravity. Thank you, Claude Code. You two are legends.

To everyone who played GunZ back in the day

I want as many old players as possible to feel this nostalgia again — no install, just click and play.

If you enjoyed this, please share it!

And yes, we have a Discord community too:

https://discord.gg/ABG8JxuBQm

20 years later, a childhood game is running inside a <canvas> tag.

The dream of bringing old games back to the web with just a click became real at exactly the right time.

If you’re a developer who geeks out over this kind of stuff, or just someone who wants to relive the glory days — I hope you give it a try.

Thanks for reading all the way to the end!

Now go click that link and kick some walls. 🚀

Whiplash GunZ Discord: https://discord.gg/ABG8JxuBQm
Play now!: https://gunz.sigr.io/

How I Fully Ported a Heavily Windows-Dependent Online Game to the Browser with WebAssembly

not a pro — Wed, 11 Mar 2026 11:30:00 +0000

Have you ever played an online PC game?

You’d wait through a painfully long download and installation, then finally launch the game — a ritual many of us remember all too well.

This time, I took GunZ: The Duel, a 2003 Windows-exclusive online TPS, and brought it fully into the browser using WebAssembly and WebGL.

No download. No installation.

Just open the page in Google Chrome.

A game that once took hours (or even days) of setup now starts with nothing more than a URL.

Doesn’t that sound exciting?

In this article, I’ll walk you through every technical challenge I tackled to make this GunZ browser port happen.

GunZ: The Duel — Now a Full Web Game

GunZ was developed by MAIET Entertainment in Korea and published in Japan by GameOn. Its signature style — wall-kicking, sword-and-gun combos, and insane aerial combat — made it a cult classic. I played it a ton back in the day.

In 2007 the entire source code (C++ client + server) leaked, and the community has been maintaining it ever since.

After more than 20 years, no one had ever managed to run it in a browser… until now.

https://gunz.sigr.io/

Just click and play. Works on Linux, macOS, iPhone, Android — literally anything with a modern browser (though phones are… let’s say “challenging” 😂).

This isn’t a “kinda works” or “looks similar” demo.

It’s the complete original game, running exactly as it did in 2003.

In this post I’ll cover:

How I actually pulled it off
Why I chose to revive a 20-year-old game right now
All the past failures that led to this moment

Past Failures and the Road to a True Browser Port

Previous Attempts (and Why They Failed)

This isn’t my first try at browser GunZ.

A few years ago I attempted to rebuild it from scratch in JavaScript + Three.js:

https://github.com/LostMyCode/three-gunz

I got map rendering working, but re-implementing the entire game engine was overwhelming. The project died quietly (the repo is still there if you’re curious).

The WebAssembly Route

GunZ is almost entirely written in C++.

We all know you can compile C++ to WebAssembly with Emscripten, so in theory it should be easy, right?

Wrong.

GunZ is extremely Windows-dependent. It calls Windows-specific APIs for rendering, audio, input — everything. The rendering engine uses Direct3D 9 directly.

Emscripten can’t magically turn Direct3D calls into something the browser understands.

So any serious port meant rewriting thousands of lines of rendering code to use WebGL instead.

No way I was doing that by hand.

That’s why the project stayed in the “theoretically possible but I’ll die before finishing” category for years.

Then AI Entered the Chat

I kept thinking: “The full C++ source code exists… there has to be a way.”

Manually rewriting everything was impossible.

But what if I let AI do the heavy lifting?

That’s exactly what I did.

I used two tools:

Google Antigravity (AI Pro plan — ¥2,900/month)
Claude Code (Max 5x plan — $100)

I started with Google Antigravity.

The AI handled:

Analyzing the massive C++ codebase
Finding every Windows API dependency
Abstracting Direct3D calls
Fixing the build system for Emscripten

The Google plan was amazing — until Google suddenly tightened the rate limits. A project this size would hit weekly quotas instantly.

So I switched to Claude Code (the $100 Max 5x plan).

Holy crap. Quotas barely moved, and bugs that had me stuck for a week were fixed in hours.

I’m not exaggerating when I say I can’t imagine working without it anymore.

The Magic Trick: Real-Time Direct3D → WebGL Translation Layer

The biggest blocker was the rendering engine — tens of thousands of lines all calling Direct3D 9 directly.

Rewriting every call was insane.

Building a full transpiler was also unrealistic.

So I did this instead:

“What if the game keeps calling Direct3D exactly as before, and I just translate every command to WebGL on the fly?”

That’s exactly what I built.

https://github.com/LostMyCode/d3d9-webgl

I inserted a translation layer between the game and the graphics API.

The original game code was left 100% untouched.

Approach	What It Means	Problem
Manually rewrite game code	Change every D3D9 call to WebGL	Tens of thousands of changes, impossible to maintain
Build a transpiler	Auto-convert D3D9 → WebGL	Semantic differences make it impossible
Translation layer	D3D9-compatible API that outputs WebGL	Only have to implement the wrapper

This approach let me remove the biggest Windows dependency without touching the original game.

(Again, mostly done by Antigravity and Claude — these AIs are terrifyingly good.)

I wrote a separate deep-dive on the D3D9→WebGL wrapper if you’re interested:

not a pro

Mar 5

d3d9-webgl — Run Legacy D3D9 Code in the Browser Without Rewriting It

#webassembly #webdev #webgl #gamedev

Comments

3 min read

Everything Else I Had to Port

Rendering was the hardest part, but it wasn’t the only one.

Network: The Server Runs Inside the Browser

This part surprises everyone.

I also compiled the original C++ server to WebAssembly and run it as a Web Worker in the same browser tab.

Instead of real network packets, the client and server talk through postMessage.

Everything runs locally in one tab.

Player data, stats, etc. are saved with SQLite + IDBFS (IndexedDB), so your progress survives tab closes — a completely serverless game server.

Of course, you can still connect to a real server via WebSocket for online play with other people.

Sound: FMOD → Web Audio API (1,260 lines)

The original game used FMOD. I replaced it entirely with the Web Audio API, re-implementing 3D spatial audio (PannerNode), BGM streaming, distance culling, and everything else the game needed.

Input: Turning Browser Events into Win32 Messages

Filesystem & Asset Loading: 2-Stage + Cache API

GunZ assets are stored in custom .mrs archives.

I load the 7 critical files first, then stream the rest (weapons, maps, etc.) in the background.

Cache API ensures second visits are instant.

Game Data Optimization (This Took Forever)

Since everything has to come over the network, I spent weeks shrinking the data.

I created version after version (default → v2 → … → v10) until load times were acceptable.

The biggest win? Converting all sound effects from WAV to Opus.

44.3 MB → 5.30 MB — an 88% reduction.

Aspect	WAV (Waveform Audio)	Opus
Compression	None (Linear PCM)	Lossy (extremely efficient)
Sound Quality	Perfect (raw)	Excellent (especially at low bitrates)
File Size	Huge	Tiny
Latency	Zero	Very low (5–26 ms)
Browser Compatibility	Universal	Modern browsers & mobile
License	Completely free	Royalty-free

Result? You can start playing in under 10 seconds.

All assets are served from S3 + CloudFront, so they load fast from anywhere in the world.

Final Thoughts

Waiting for the right moment was key.

I knew almost nothing about WebGL or Direct3D. If I had tried this five years ago, I would have given up.

But in the AI era, it finally became possible.

Thank you, Antigravity. Thank you, Claude Code. You two are legends.

To everyone who played GunZ back in the day

I want as many old players as possible to feel this nostalgia again — no install, just click and play.

If you enjoyed this, please share it!

And yes, we have a Discord community too:

https://discord.gg/ABG8JxuBQm

20 years later, a childhood game is running inside a <canvas> tag.

The dream of bringing old games back to the web with just a click became real at exactly the right time.

If you’re a developer who geeks out over this kind of stuff, or just someone who wants to relive the glory days — I hope you give it a try.

Thanks for reading all the way to the end!

Now go click that link and kick some walls. 🚀

d3d9-webgl — Run Legacy D3D9 Code in the Browser Without Rewriting It

not a pro — Thu, 05 Mar 2026 14:50:12 +0000

I ported a 2003 online game to the browser. The game was written in C++ with Direct3D 9. Emscripten handles the C++-to-Wasm part fine, but the moment you #include <d3d9.h>, the build dies — that header only ships with the Windows DirectX SDK.

The obvious options all sucked:

Approach	Problem
Rewrite the renderer in WebGL / Three.js	You're basically rewriting the game
Convert D3D9 calls to OpenGL one by one	Still a massive rewrite
Re-implement the D3D9 API itself, backed by WebGL	The existing code doesn't need to change

So I went with option 3 and built d3d9-webgl: a header + source file set that implements D3D9 interfaces on top of WebGL 2.0. You drop it into an Emscripten project, and your D3D9 code compiles and runs in the browser as-is.

Does it actually work?

The game I was porting is GunZ: The Duel (2003). The rendering code required almost no changes. You can play it at gunz.sigr.io.

Whiplash GunZ

Play the classic GunZ Online in your browser. No download required.

gunz.sigr.io

How it works

IDirect3D9, IDirect3DDevice9, IDirect3DTexture9 — all the COM interfaces are re-implemented. When your app calls IDirect3DDevice9::DrawPrimitive(), the wrapper translates it to glDrawArrays() internally. The application can't tell the difference.

The hard parts

Rebuilding the Fixed Function Pipeline in GLSL

D3D9's FFP — SetLight, SetMaterial, SetTransform — doesn't exist in WebGL 2.0. I had to write GLSL shaders that replicate the entire lighting model: World/View/Projection transforms, normal transforms, per-vertex diffuse + specular for up to 3 point lights in the vertex shader, and texture blending + color composition in the fragment shader.

This was the most time-consuming part of the whole project.

Parsing FVF at runtime

D3D9 vertex buffers use Flexible Vertex Format (FVF) — bit flags that describe the vertex layout. The wrapper parses these at runtime to set up glVertexAttribPointer with the right stride and offset.

// Position + Normal + Vertex Color + 1 UV set
DWORD fvf = D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_DIFFUSE | D3DFVF_TEX1;

Texture format mismatches

D3D9 uses BGRA; WebGL wants RGBA. A8R8G8B8 gets swizzled on upload. 16-bit formats like R5G6B5 and A4R4G4B4 are expanded to RGBA8.

DXT1/DXT3/DXT5 compressed textures are passed straight through — the WEBGL_compressed_texture_s3tc extension covers this on pretty much every desktop browser.

Y-axis flip

D3D9: top-left origin, Y goes down. OpenGL: bottom-left origin, Y goes up. When rendering to an FBO via SetRenderTarget, the image ends up flipped. The wrapper compensates during StretchRect blit to screen. Direct screen rendering doesn't need the fix.

Clip planes via `discard`

WebGL has no hardware clip planes. The fragment shader calculates clip-plane distance and discards fragments on the wrong side. Simple, but one of those things you don't think about until everything clips wrong.

State caching

D3D9 apps call SetRenderState / SetTexture / SetSamplerState hundreds of times per frame, and most of those calls set the same value that's already set. The wrapper caches everything — texture bindings, shader programs, sampler states, viewport, scissor — and only issues a GL call when something actually changes.

Usage

Copy five files into your project:

d3d9.h — D3D9 type definitions & interfaces
d3d9.cpp — WebGL 2.0 implementation (~3,400 lines)
d3dx9math.h — D3DX math library
d3dx9.h — D3DX stubs
windows_compat.h — Windows API stubs

CMake:

add_executable(my_app main.cpp d3d9.cpp)
target_link_options(my_app PRIVATE
    -sUSE_WEBGL2=1
    -sFULL_ES3=1
    -sWASM=1
    -sALLOW_MEMORY_GROWTH=1
)

emcmake cmake .
emmake make

That's it.

Limitations

FFP only. HLSL vertex/pixel shaders are not supported. The wrapper reports VertexShaderVersion = 0, so applications with shader code paths need to fall back to FFP.

Other limitations:

Max 3 point lights (no directional or spotlights)
Vertex buffer stream 0 only
No LockRect on render targets (no GPU readback)
D3DXMatrixInverse is stubbed (returns identity)

In practice, most games and tools from the early 2000s used FFP anyway. Programmable shaders only became common in the later DX9 era, so anything before ~2005 is likely covered.

Why I'm releasing this

While building the GunZ port, I kept searching for something like this. It didn't exist. I spent a lot of time writing this wrapper, and I figured someone else out there is probably stuck on the same problem right now.

If you have an old D3D9 codebase and you've been curious about running it in a browser — try it out and let me know how it goes.

GitHub: d3d9-webgl

LostMyCode / d3d9-webgl

Direct3D 9 Fixed-Function Pipeline → WebGL 2.0 wrapper for Emscripten/WASM

d3d9-webgl

A Direct3D 9 Fixed-Function Pipeline implementation targeting WebGL 2.0 via Emscripten/WebAssembly.

Drop-in D3D9 headers and a single .cpp file that translates D3D9 API calls to WebGL — enabling legacy D3D9 applications to run in the browser without rewriting their rendering code.

01 — Rotating Cube Textures, VB/IB, DrawIndexedPrimitive	02 — FFP Lighting 3 Point Lights, Materials, DrawPrimitiveUP

✨ Features

Full FFP Emulation — Per-vertex lighting (3 point lights), materials, texture stage states, transform matrices
All Draw Paths — DrawIndexedPrimitive, DrawIndexedPrimitiveUP, DrawPrimitiveUP, DrawPrimitive
FVF Parsing — Automatic vertex layout from D3DFVF_XYZ, D3DFVF_XYZRHW, D3DFVF_NORMAL, D3DFVF_DIFFUSE, D3DFVF_TEX1–TEX8
Texture Formats — DXT1/3/5 (via S3TC extension), A8R8G8B8, X8R8G8B8, R5G6B5, A4R4G4B4, A1R5G5B5, R8G8B8
Linear Fog — Per-pixel D3D9 table fog (D3DRS_FOGENABLE, D3DRS_FOGCOLOR, D3DRS_FOGSTART, D3DRS_FOGEND); automatically skipped for D3DFVF_XYZRHW vertices
Render States — Alpha blending, alpha test, depth test, stencil operations, culling…

View on GitHub

Issues and PRs welcome.

Forem: not a pro

The Crazy Way a Dev Avoided Copyright on Leaked Claude Code

Leak → Immediate Backup → DMCA Blitz

Then Came the “God-Tier Evasion”

Why Does This Bypass Copyright Infringement?

What This Means: “The Collapse of Copyright in the AI Era”

In Conclusion

Claude Code Turned a 2003 Windows Game into a Browser Game

GunZ: The Duel — Now a Full Web Game

Previous failures and the road to full browser port

Past attempts that failed

The WebAssembly Route

Then the AI era arrived

How we removed the Windows dependency — real-time Direct3D → WebGL translation

d3d9-webgl — Run Legacy D3D9 Code in the Browser Without Rewriting It

Everything Else I Had to Port

Network: The Server Runs Inside the Browser

Sound: FMOD → Web Audio API (1,260 lines)

Input: Turning Browser Events into Win32 Messages

Filesystem & Asset Loading: 2-Stage + Cache API

Game Data Optimization (This Took Forever)

Final Thoughts

Sometimes you just have to wait for the right time

To everyone who played GunZ back in the day

How I Fully Ported a Heavily Windows-Dependent Online Game to the Browser with WebAssembly

GunZ: The Duel — Now a Full Web Game

Past Failures and the Road to a True Browser Port

Previous Attempts (and Why They Failed)

The WebAssembly Route

Then AI Entered the Chat

The Magic Trick: Real-Time Direct3D → WebGL Translation Layer

d3d9-webgl — Run Legacy D3D9 Code in the Browser Without Rewriting It

Everything Else I Had to Port

Network: The Server Runs Inside the Browser

Sound: FMOD → Web Audio API (1,260 lines)

Input: Turning Browser Events into Win32 Messages

Filesystem & Asset Loading: 2-Stage + Cache API

Game Data Optimization (This Took Forever)

Final Thoughts

To everyone who played GunZ back in the day

d3d9-webgl — Run Legacy D3D9 Code in the Browser Without Rewriting It

Does it actually work?

Whiplash GunZ

How it works

The hard parts

Rebuilding the Fixed Function Pipeline in GLSL

Parsing FVF at runtime

Texture format mismatches

Y-axis flip

Clip planes via discard

State caching

Usage

Limitations

Why I'm releasing this

LostMyCode / d3d9-webgl

Direct3D 9 Fixed-Function Pipeline → WebGL 2.0 wrapper for Emscripten/WASM

d3d9-webgl

✨ Features

Clip planes via `discard`