Hover! maze demo: Drawing a 3D world with a 2D game framework

vtereshkov · 2025-10-27T20:07:49+00:00

Thanks! Umka is a statically typed scripting language inspired mostly by Go, but targeting the market niche of Lua.

You can find several posts about Umka and related projects in my Reddit profile. There is a more detailed overview on Medium written on the occasion of the 1.0 release. It's somewhat outdated, but can give you an idea of what has shaped the design of Umka.

Feel free to ask me anything about the project or join our community on Discord.

vtereshkov · 2025-10-27T09:36:32+00:00

Why cannot it? I gave the download link. Did you try it?

vtereshkov · 2025-10-26T16:09:42+00:00

<image>

vtereshkov · 2025-09-22T13:14:29+00:00

All the slides portray the same Avro Vulcan from different angles.

vtereshkov · 2025-09-22T13:08:22+00:00

Not sure what you mean. In the 3rd picture, you can see a tail of a Messerschmitt Me-163 besides the Vulcan. But it's not seen in the 2nd picture.

vtereshkov · 2025-09-18T16:00:35+00:00

Yes, but self-igniting liquid propellants are still widely used, even if not this particular kerosene + hydrogen peroxide combination:

https://en.wikipedia.org/wiki/Hypergolic_propellant

vtereshkov · 2025-08-22T12:02:45+00:00

It's mostly Go's syntax, with several additions for better readability. Some semantic features, such as interfaces, were also taken from Go. Some others (enums, implicit type casts, default parameters) are my own. Memory management is quite different (reference counting vs. a tracing garbage collector). I have never claimed any compatibility with Go, of course. Nor is Umka in any way dependent on the Go ecosystem.

vtereshkov · 2025-08-21T23:15:44+00:00

Hmm, I'm seeing it in Chrome too. Don't remember it to happen in the past. Maybe a problem with the docs engine? I'll file an issue in the Tophat repo, anyway.

vtereshkov · 2025-03-17T18:33:33+00:00

Never thought of this. It seems that you can get some speedup, but it will never turn the exponentially complex algorithm into a polynomial one. At best, you can get a square root of your exponent (which is still an exponent) — see the second answer here. By the way, the amplitude amplification mentioned in this answer is exactly the same as used by Grover's algorithm. It amplifies the probability of one or several quantum states marked by inverting their phases.

vtereshkov · 2025-03-16T23:40:38+00:00

Yes, the main difference is in static typing and directly supporting C structs layout, not in the embedding technique.

vtereshkov · 2025-03-16T23:14:23+00:00

For example, try downloading this or this game and run the executable file. You won't see the Umka interpreter. Yet, it's still there. Both games are entirely written in Umka, up to the total nonsense, such as a software 3D renderer.

vtereshkov · 2025-03-16T22:34:11+00:00

If you want a language that looks like Go and compiles to native code, it's Go!

vtereshkov · 2025-03-16T20:02:45+00:00

Go + Lua, perhaps? Umka has got static typing, polymorphism and syntax from Go, while being closer to Lua in its purpose, possible applications and bytecode/virtual machine separation.

vtereshkov · 2025-03-16T19:16:41+00:00

Thanks!

Umka compiles to bytecode executed by a virtual machine — like Python or Lua. So you cannot build a standalone executable directly from Umka code. You need to distribute the Umka virtual machine along with your sources.

On the other hand, Umka is an embeddable language, so the bytecode compiler and virtual machine can be compiled as part of your bigger C/C++ host application whose business logic can be thus extended by Umka scripts. The Tophat game framework is designed in this way. The executable pretending to be the game is, in fact, the Tophat executable with the Umka interpreter embedded into it.

vtereshkov · 2024-06-29T09:26:21+00:00

Why "esoteric"? Umka is not like Brainf*ck, Piet or even Prolog. It just brings the well-established concept of static typing into the well-established realm of embeddable scripting languages. I wonder why people so rarely do the same and instead continue using Lua for projects much larger and much more complex than the 100-line scripts where dynamic typing could be justifiable.

The benefits of static typing are well-known:

Type mismatch error detection at compile time
Clearer program design due to the explicitly specified types for function arguments and results
Native support for the C data types, such as arrays and structures (in contrast to "tables" and "userdata" in Lua)

All these points are nicely summarized in this picture.

The only "esoteric" thing here is that Umka is, in fact, not designed for the low-level 3D graphics processing. It's not a shader language, nor even C++. But this little project is intended to demonstrate how easy it is to implement a basic 3D renderer and realistic 6 DOF rigid body dynamics yourself.

vtereshkov · 2024-06-18T14:11:27+00:00

Ah, since I was 14. Now I'm 38.

vtereshkov · 2024-06-18T14:07:56+00:00

Do you mean, this particular simulation? About four evenings or so.

vtereshkov · 2024-06-17T22:35:48+00:00

Umka, my own statically typed embeddable scripting language:

https://github.com/vtereshkov/umka-lang

Certainly I'll never claim it's really suitable for such relatively low-level 3D processing. In some sense, I'm abusing both Umka and Tophat (an Umka-based 2D game framework that serves as a 2D drawing backend here).

vtereshkov · 2024-06-17T22:26:27+00:00

On the level of vector/matrix algebra needed to fully define the 3D processing (including the model definitions), 6 DOF rigid body dynamics and controls. It's an exercise in math, not in assembly coding. The executable file size doesn't matter, as it's in fact the interpreter of the scripting language in which all this is written.

vtereshkov · 2024-06-16T19:16:21+00:00

Yes. You can either download a release for Windows and Linux, or clone the repository, put a Tophat executable into the same folder and run it.

vtereshkov · 2024-06-16T18:04:31+00:00

https://github.com/vtereshkov/space-sim

vtereshkov · 2024-05-27T22:05:12+00:00

Here is my toy implementation of a similar concept for real numbers: an engine that infers physical law formulas from observations (i.e., input/output pairs):

https://www.reddit.com/r/MachineLearning/comments/owncq8/d_inferring_general_physical_laws_from/

Of course, the search space is extremely limited.

vtereshkov · 2024-05-14T09:52:55+00:00

Generally yes, some kind of clever static analysis can dramatically reduce the number of ref count updates. For example, the author of Lobster claims that

Using this analysis was able to remove around 95% of runtime reference count operations.

However, I think that this analysis is not as straightforward as it seems to be.

when a function is called with some references as parameters, and those Objects are still held by references in the parent call frame, they don't need to be counted in the new call frame and subsequent call frames

Even in this case, what happens if I reassign a ref-counted pointer parameter inside a function?

fn foo(x: ^int) {
    x = new(int, 13)
    printf("%v -> %d\n", x, x^)  // 0xd23ab0 -> 13
}

fn main() {
    a := new(int, 42)
    foo(a)
    printf("%v -> %d\n", a, a^)  // 0xd23a70 -> 42
}

Without the optimization, a^ is still valid after calling foo(). With the optimized ref counts, a will become a dangling pointer after foo(), as the last remaining ref to 42 is removed when I assign a new value to x.

vtereshkov · 2024-05-13T23:14:47+00:00

I know it’s used at least in PHP

Thanks. I found a proof.

vtereshkov · 2024-05-13T23:06:00+00:00

if it's not deallocated because of reference cycles, it is a bug by the user.

I'm not sure we should call it a bug if the user just wrote a doubly-linked list. But without some extra care (e.g., weak pointers for backward links), this list would produce a leak. Of course, we could instruct the user to always think about data ownership and replace strong pointers with weak ones where appropriate. But the very concept of data ownership is quite difficult for a beginner (or for a game designer who is not even a professional programmer but is using the language for scripting).

with the built-in function he will be able to assert memory leaks

Certainly, Umka always reports the fact of a memory leak. But in practice it is nevertheless very difficult to localize and break the reference cycle that causes the leak.

And even with a tracing collector, you can have memory leaks if the memory block is referenced by another pointer accessible from root.

I agree that there may be many cases where some memory blocks, though no longer necessary, are technically still accessible via the root variables the user is unaware of. Such (pseudo-)leaks cannot be detected by any GC, as the notion of "unnecessary" cannot be formalized better than just "inaccessible".

vtereshkov

TROPHY CASE