|
|
@@ -79,6 +79,20 @@ There's a comment at the top of that file on how to use the `build_web_example`
|
|
|
> [!NOTE]
|
|
|
> Desktop programs can have the whole program in a `main` procedure. But web builds need to be split into `main` and `step` procedures, where `step` is called each frame by the browser in order to create a "game loop"
|
|
|
|
|
|
+## Architecture notes
|
|
|
+
|
|
|
+The platform-independent parts and the main API lives in `karl2d.odin`
|
|
|
+
|
|
|
+`karl2d.odin` in turn has a window interface and a rendering backend.
|
|
|
+
|
|
|
+The window interface depends on the operating system. I do not use anything like GLFW in order to abstract away window creation and event handling. Less libraries between you and the OS, less trouble when shipping!
|
|
|
+
|
|
|
+The rendering backend tells Karl2D how to talk to the GPU. I currently support three rendering APIs: D3D11, OpenGL and WebGL. On some platforms you have multiple choices, for exmaple on Windows you can use both D3D11 and OpenGL.
|
|
|
+
|
|
|
+The platform indepdentent code in `karl2d.odin` creates a list of vertices for each batch it needs to render. That's done independently of the rendering backend. The backend is just fed that list, along with information about what shader and such to use.
|
|
|
+
|
|
|
+The web builds do not need emscripten, instead I've written a WebGL backend and make use of the official Odin JS runtime. This makes building for the web easier and less error-prone.
|
|
|
+
|
|
|
## Is this a Raylib clone?
|
|
|
|
|
|
The API was originally based on Raylib API, because I like that API. But I have changed things I don't like about Raylib and made the API more Odin-friendly. The implementation is meant to have as few dependencies as possible (mostly `core` libs and some libraries from `vendor`). The web builds do not need emscripten, it uses Odin's js_wasm32 target.
|
Karl Zylinski