Karl2D beta is here!

Hi everyone! Since the last newsletter I’ve released a beta version of the “Karl2D” library!

It’s a 2D game creation library written in Odin that tries to be beginner friendly while also minimizing the number of dependencies. The focus is “easy to get started with, easy to ship the game”.

“easy to ship” actually never happens… Shipping games is always hard. What I mean is: Less problems due to the library you use, and easier to fix the problems when they do occur!

You’ll find the library here: https://github.com/karl-zylinski/karl2d

In the beta version that I just released, the feature set is as follows:

• Rendering of shapes, textures and text with automatic batching

• Support for shaders and cameras

• Windows support (D3D11 and OpenGL)

• Mac support (OpenGL)

• Linux support (OpenGL)

• Web support (WebGL, no emscripten needed!)

• Input: Mouse, keyboard, gamepad

Ok, that’s cool. Show me some examples!

A basic “hellope world” example would be this:

package hello_world

import k2 "karl2d"

main :: proc() {
	k2.init(1280, 720, "Greetings from Karl2D!")

	for k2.update() {
		k2.clear(k2.LIGHT_BLUE)
		k2.draw_text("Hellope!", {50, 50}, 100, k2.DARK_BLUE)
		k2.present()
	}

	k2.shutdown()
}

And it would look like this:

Or you can see it running in a browser here.

That’s not all that fun though. It’s just a piece of text, nothing interactive! Here are some more advanced live web examples, with their source code linked:

Basics example — Source here (draw textures and simple movement code)

Camera example — Source here (movable and rotatable camera, thank you to a contributor for making this example)

How the Camera example looks

In the library’s README I show how to make these web builds. You can make both ordinary desktop games as well as web builds. The web builds will be very handy for game jam creations and such. The fact that they do not need emscripten makes the whole process a lot smoother, compared to creating Raylib web builds.

If you try the library out and want to show what you made, do please join my Discord server and post a video or web build link! :)

Platform architecture shenanigans

In previous newsletters I’ve talked about avoiding extra dependencies in order to make things more understandable and easily modifiable for you, the game dev!

I have some new fresh examples of this in this beta version. The current platforms are Windows, Linux, Mac and Web.

The Windows platform code you can see in platform_windows.odin — That one implements the windowing, events and gamepad support. It’s plain win32 API code without any other library in-between. If you have a Windows-only bug and you are stressed because you need to ship your game soon, then don’t worry. You can just go in and poke in that Windows platform code without affecting any other platform. No need to recompile some additional C library in debug mode and look for bugs in there. Odin libraries come as source, so you just make changes in the Karl2D source and recompile your game. Easy as PI.

The Linux platform code is quite different. You can see it in platform_linux.odin — There is no windowing code in there! The reason for this is that Linux doesn’t have a single windowing system. These days people use both X11 and Wayland. So instead of throwing in some bindings to some C library that talks to both, me and a contributor have added support for both! In platform_linux_window_x11.odin and platform_linux_window_wayland.odin you see the windowing code that the Linux platform layer calls into, depending on which is currently used.

Adding Wayland support wasn’t all that easy because Wayland is strange. It’s the new fancy Linux thing for managing windows that is supposed to replace X11. In order to talk to it we had to make bindings for something called libwayland.

libwayland isn’t much of a library: It’s just a client that can throw things to the Wayland server using the Wayland protocol. In order to figure out what is possible to communicate using the protocol you parse XML files that tell you what is available… Yes… Parse XML files, to generate code, in order to use a protocol, in order to open a window… 🙀

A much better idea would have been a plain C library!! They could make an extension mechanism for it and adding versioning of APIs wouldn’t be hard either.

I was literally laughing while working on the Wayland windowing. It was like a parody YouTube video about over-engineering. But it’s the new thing!! The thing that is going to save Linux and start The Year of Linux on the Desktop!!! AAAAAAAAAAAAaaaa

Wayland really is the worst windowing API I’ve ever used. Win32 and even X11 feels like a refreshing day in the sun in comparison.

Anyways. We managed to tame the Wayland beast. Phew.

You may say: “But if you used SDL or GLFW then you would just have 1 library to talk to!! Now you have Win32, Wayland, X11 and more. Isn’t that adding dependencies? You wanted to avoid dependencies!! But you are ADDING MORE!!!”

In my opinion, the “quote” above is the wrong way to think about this. If you think about it, SDL and GLFW has dependencies on Win32, X11, Wayland etc. So if you use for example GLFW, then you still have dependencies on Win32, X11 and Wayland, but with another another layer in-between. That extra layer is another dependency. And that layer is annoying to change, because it is written in C, and it does lots of things I do not need.

Anyways, I am happy with how the platform code has turned out. With the help of some contributors, we’ve been able to also build gamepad support for Mac and Linux. On Linux it goes straight to udev/evdev and talks to the gamepads that way. It’s pretty cool! It currently supports XBox and PlayStation controllers; give it a go! Here’s a web version of the gamepad example (the web version does not have vibration currently, I’ve put that off for some reason).

On Mac we’ve used the Cocoa framework for windowing and GameController + CoreHaptics for gamepads + vibration. Those are native OS libraries that are included on Mac. They seem to be at a reasonable abstraction level. Thanks to contributors for figuring that stuff out; I don’t have a recent enough mac to get that work done.

What’s missing?

This beta (known as Beta 2) does not have the follow features, but they are planned in the order stated:

• Sound

• System for cross-compiling shaders between different backends (HLSL, GLSL, GLSL ES, MSL etc)

• Metal rendering backend for Mac (OpenGL already works)

I have a few small tasks to do before starting on sound. My idea for sound is to write a software mixer and then output the audio directly to the low-level audio interfaces of each platform.

Support the development of Karl2D

If you want to support the development financially, then I’d be very grateful! You can do so by becoming a sponsor on either GitHub or Patreon. The money will be used to make me able to spend more hours on this project.

Wanna do open-source contributions to odin-c-bindgen?

My C library binding generator needs help! I don’t have time to fix bugs for it currently. If you want to help then please check out the section called Contributing on its GitHub page. Thank you to all past contributors!

Bye bye, have a nice day!

/Karl Zylinski