How Aevocraft works

Minecraft Java Edition was designed for a desktop JVM, native desktop APIs and an OpenGL rendering stack — not for a browser.

Aevocraft works by adapting those platform boundaries while preserving the Java client's behavior as closely as practical.

The execution gap

A browser cannot simply launch a Java desktop application.

It does not expose the same filesystem, native windowing APIs, OpenGL context, raw TCP sockets or threading model expected by a traditional Minecraft Java client.

The challenge is therefore not to redraw a Minecraft-like world. It is to make the client survive in a completely different execution environment.

Java to browser

Aevocraft uses TeaVM as part of the build pipeline to transform the Java application for execution on the web.

Desktop-only Java behavior and libraries that do not exist in a browser require compatibility work around the client.

OpenGL to WebGL2

Minecraft 1.20.4 uses a desktop OpenGL rendering pipeline.

Aevocraft provides browser-side graphics compatibility so the client's rendering work can be translated into WebGL2 and presented through an HTML canvas.

This includes adapting shader behavior, buffers, textures, framebuffer operations and other assumptions that differ between desktop OpenGL and WebGL.

Desktop loop to browser loop

A desktop game can own its main thread and run a traditional blocking loop. A browser cannot.

Aevocraft adapts frame scheduling to the browser while mapping keyboard, mouse and pointer-lock input back into the client's expected input model.

TCP to WebSocket to TCP

Minecraft Java servers normally speak raw TCP.

Web pages cannot open arbitrary raw TCP sockets, so Aevocraft uses a browser-compatible WebSocket connection to a relay. The relay forwards the binary traffic to the target Java server over TCP.

Browser-native storage

Resources and runtime data that would normally live on a desktop filesystem need browser-safe equivalents.

Aevocraft can use browser storage and caching mechanisms to avoid treating every launch like a completely new desktop installation.

Change the platform, not the game.

The guiding principle is to replace desktop-specific dependencies only where the browser requires it.

Rendering backends, window/input APIs, scheduling, storage and networking need adaptation. Core client behavior should remain as close to the Java Edition client as the browser environment allows.