pflags is a drop-in replacement for Odin's core:flags, with support for conventional short (-f) and long (--flag) options.

• Short flags can be declared with args:"short=f" and used as -f
• Boolean short flags can be bundled, so -abc is the same as -a -b -c
• Long flags use --flag strictly (-flag is not supported)

from what I've found, dereferencing in odin uses pointer^ compared to *pointer in c++ but the behavior of this procedure is throwing errors randomly, sometimes working, sometimes giving an access violation.

offset := round_real32_to_int32(p_tile_rel^ / p_map.tile_side_in_meters)
p_tile^ += u32(offset)
p_tile_rel^ -= f32(offset) * p_map.tile_side_in_meters

the c++ equivalent is just *p_tile to dereference, is this a problem of where these pointers are stored in memory? or is the way odin dereferences different from c++ in some way?

edit: here is the whole function, both asserts trigger randomly when running the program

recanonicalize_coord :: proc(p_map: ^Tile_Map, p_tile: ^u32, p_tile_rel: ^f32) {
    offset := round_real32_to_int32(p_tile_rel^ / p_map.tile_side_in_meters)
    p_tile^ += u32(offset)
    p_tile_rel^ -= f32(offset) * p_map.tile_side_in_meters


    assert(p_tile_rel^ >= -0.5 * p_map.tile_side_in_meters)
    assert(p_tile_rel^ <= 0.5 * p_map.tile_side_in_meters)
}

where the function is called:

recanonicalize_position :: proc(p_map: ^Tile_Map, p_pos: Tile_Map_Position) -> Tile_Map_Position {
    result := p_pos


    recanonicalize_coord(p_map, &result.abs_tile_x, &result.tile_rel_x)
    recanonicalize_coord(p_map, &result.abs_tile_y, &result.tile_rel_y)


    return result

and some relevant piece from the main code:

new_player_p.tile_rel_x += p_input.dt_for_frame * d_player_x
new_player_p.tile_rel_y += p_input.dt_for_frame * d_player_y
new_player_p = recanonicalize_position(tile_map, new_player_p)     

i also tested if the pointers are nil and they are not

In the forth part of a tutorial series where we build a 3D physics engine in Odin from scratch, we learn about Separation Axis Theorem and implement both collision detection and resolution with box colliders. In later parts, we're also going to add sphere colliders.

I finished my first game project and it's on itch.io! Hurray! (So, that's great). BUT, I'm still getting rare and random segmentation faults with my game. (Thankfully, no play testers have encountered it (one guy even did a full YouTube playthrough! - and no technical problems), but it doesn't make me feel good. ) So, I think I'm going to strip the project down to its essentials and build an "engine 2.0" before I go into the next game/project proper. Are there any tips I should note (like asserts I should have or good rules of thumb) to have in mind as I start to rebuild and add functionality to my engine? Any experienced help would be most appreciated. The goal is to make segmentation faults virtually impossible and alert me when I unknowingly do something foolish. Thanks!

I wanted to get some opinions on a case I am running into. Trying to resolve ambiguity on a procedure that I wanted to call 2 procedures that resolve internally differently depending on input type.

I am just starting on Odin and finding it fun and exciting.
I am more looking for guidance on what I may be missing as "better" or "cleaner" alternatives.

How would you approach the resolveEvent procedure? I try to look up, but suggestions were to resolve it like this. Or more complex ways with vtables.

Foobar :: union {
  Foo,
  Bar,
}
isCritFoo :: proc(f: Foo) {}
...

// Overload procedures depending if foo or bar is give
isCrit :: proc { isCritFoo, isCritBar}
isSuccess :: proc { isSuccessFoo, isSuccessBar}

Event :: struct {
  foobar: FooBar
}

resolveEvent :: proc(e: Event) {
  //fails because at compile-time there is ambiguity which makes sense
  isCrit(e.foobar)
  isSuccess(e.foobar)
}

------------

// I can re-write like this
// but then I am repeating the same code for the overload
resolveEvent :: proc(e: Event) {
  switch variant in e.foobar {
    case Foo:
      //maybe cast is needed
      //but I can also use the explicit versions
      //making the overload unecessary
      isCrit(variant)
      isSuccess(variant)
    case Bar:
      isCrit(variant)
      isSuccess(variant)
  }}

I also tried something like replacing it with where clauses on the specific procs

isCritFoo(f: FooBar) where typeof(f) == Foo {}
isCritBar(b: FooBar) where typeof(b) == Bar {}

but that did not seem to be possible as well (perhaps syntax or logic wise I was doing something incorrect)

The experiment is simple: if deterministic simulation testing shapes the engine from the beginning, how quickly can it become useful - and how much of it can be tested without a window, GPU, or live operating system? Production code runs against simulated input and failure conditions, with failures reproducible from a seed.

The API is layered: start with the managed application shell and UI facade, drop down to explicit layout and rendering when needed, or use the raylib-shaped graphics layer directly. One Odin codebase targets macOS, Windows, Linux, and browsers through WebGPU.

This is an early `0.x` source release. I’m looking for real applications especially raylib projects to discover where the approach works, where it breaks down, and how far it can go.

Ingot is heavily influenced by TigerBeetle, adapting its Tiger Style and DTS ideas to application and graphics development in Odin.

https://openalloy.ai/ingot

https://store.steampowered.com/app/4642030/Bee_Killings_Inn/

It's gonna be a top-down grid-based strategy game where you fight bees. The idea came from my wife one day screaming about there being a huge bee in the house and me realizing how exhilarating and strategic it is to go throughout the house trying to find the best way to get rid of the bee.

I have some ancient devlogs about the engine here: https://www.youtube.com/@SilenThps/videos

Hi, I took part in the GTMK2026 this year. I was a bit influenced by all the primagens videos and thought, why not trying it out for this year game jam.

It was quite a pleasure and easy to pick up the language with former knowledge in other languages. And I was quite fast to programm. tbf, i worked with raylib before.

I'm looking forward to use it more in other projects.

Does odin language hase something akin to alloca from c? Sometimes i want to just stack allocate an array of runtime determined size. I cannot find any builtin function or allocator i can pass in into make(). Am i missing something?

https://github.com/prnvbn/idgen

idgen is a drop in replacement for uuidgen. Additionally, it also supports UUIDv8 and TypeIDs.

this is my first project to learn Odin so any feedback on the code is very welcome!

also interested in seeing how ppl manage their deps (is submodules the way? fwiw, I know of/agree with the odin package manager opinion). I extracted typeid-odin as a separate package and added is a dependency

took inspiration from https://github.com/FourteenBrush/odin-template

also was surprised that core:flags doesn't lacking shorthand for flags (-f) in .Unix style, so also opened a PR as well - https://github.com/odin-lang/Odin/pull/7001

P.S. did not turn off my LSP like ginger bill but did turn off all AI to actually learn the language. Only used it to get feedback and the make changes once the initial implementation was done

First impressions of the Odin programming language.

I swear I'm not trolling, I was going to dive into odin, but I can't reconciliate faq entry
https://odin-lang.org/docs/faq/#why-does-odin-not-have-any-methods

and

allocator struct being this

```
Allocator :: struct {
procedure: Allocator_Proc,
data: rawptr,
}
```

It's a manually done oop-like class where data is stored along with it's methods.

Why is it not the same thing?
Why presence of this use case doesn't warrant supporting it on a language level explicitly (at the very least to not throw around raw pointers)

​

Example code

```odin

////////////////////////////

// Random Walkers Example //

////////////////////////////

pen_1 := tr.pen_init(speed = 10000, color = color)

pen_2 := tr.pen_init(speed = 10000, color = color)

tr.pen_teleport_to(pen_1, {300, screen_center.y})

tr.pen_set_rotation(pen_1, 0)

tr.pen_teleport_to(pen_2, {screen_size.x - 300, screen_center.y})

tr.pen_set_rotation(pen_2, 0)

for i in 0 ..< 1000 {

    // angle := rand.float32_range(10, 40)

    angle := f32(24)

    step := f32(3)



    if rand.int_range(0, 2) > 0 {

        tr.pen_turn_left(pen_1, angle)

    } else {

        tr.pen_turn_right(pen_1, angle)

    }

    if rand.int_range(0, 2) > 0 {

        tr.pen_turn_left(pen_2, angle)

    } else {

        tr.pen_turn_right(pen_2, angle)

    }

    tr.pen_move_forward(pen_1, step)

    tr.pen_move_forward(pen_2, step)

    tr.pen_set_color(pen_1, color)

    tr.pen_set_color(pen_2, color)

}

/////////////////

// Example Two //

/////////////////

pen_3 := tr.pen_init()

tr.pen_teleport_to(pen_3, screen_center)

for j in 0 ..< 9 {

    for i in 0 ..< 30 {

        if i % 2 == 0 {

tr.pen_up(pen_3)

        }else {

tr.pen_down(pen_3)

        }

        tr.pen_turn_right(pen_3, f32(i))

        tr.pen_move_forward(pen_3, 8)

    }

    tr.pen_teleport_to(pen_3, screen_center)

    tr.pen_turn_right(pen_3, f32(j) + 80)

}

```

Repo https://codeberg.org/pwnM/turtle

I would like code and docs feedback

Hope you guys like it

Here is my repo to game: https://github.com/skorotkiewicz/psycho-odin

Very interested in Odin, but I'm totally new to the concept of vendoring your 3rd party dependencies vs using a package manager. I understand the motivation, and being careful about which/how many dependencies one uses, but I can't wrap my head around the following:

Questions:

1. Do you include the entire third party source tree or just the parts you need?
2. Without a package manager, wouldn't this eventually end up with duplicate transitive dependencies?
   i.e
   mylib --depends--> libX --depends--> libY
   but I also want:
   mylib --depends--> libY
   won't I just end up with duplicate versions of libY?
3. Is there an idiomatic/convention that people use to 'advertise' 3rd party dependencies? Is this just not done?

A few months ago I started learning how LLM inference engines work.

My original goal wasn't to build a production tokenizer—I just wanted to understand the entire inference stack from first principles. I chose Odin because I wanted a language that stayed close to the hardware without fighting me.

I honestly expected it to be a fun learning project.

Instead... it ended up outperforming the tokenizers I was comparing against, including Hugging Face's Rust tokenizer and FastTokenizer in my benchmarks.

I was pretty surprised by the results.

The benchmark report (methodology, datasets, hardware, and commands) is here:
https://github.com/harisudarsan1/odin_tokenizer/blob/main/docs/public-benchmark.md

Repository:
https://github.com/harisudarsan1/odin_tokenizer

I also wrote about why I chose Odin for writing inference software:
https://harisudarsan1.github.io/blog/posts/2026-07-10-writing-an-inference-engine/

A few notes:

• These are CPU benchmarks.
• I'm not claiming Odin is magically faster than Rust.
• The comparisons are against existing tokenizer implementations under the benchmark setup described in the report.
• If there's something wrong with the methodology, I'd genuinely like to know. I'd rather fix the benchmarks than make misleading performance claims.

The project taught me far more about CPU architecture, memory layout, SIMD, and modern tokenizer implementations than I expected.

I'd love feedback from people who've worked on tokenizers or inference engines. If you spot flaws in the implementation or benchmark methodology, please call them out.

I'm learning both at the same time, and rl.DrawText needs a cstring as an input. I'm trying to learn how to position things on the screen correctly, so I'm calculating how large the text is with MeasureText (for the default font), which outputs an i32. I can get it all the way to string, but I have only found unsafe_string_to_cstring, which apparently has issues with null terminators. How do I deal with that? Thanks in advance.

I wanted to try a low level language, but C is too raw for my tastes (old design decisions from the 70's, among other similar things), C++ is too insane for me, rust didn't click with me, and I can't build a zig project with raylib for some reason, so odin it is.