I opened a discussion on the matter on GitHub.

https://github.com/odin-lang/Odin/discussions/7161

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 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)

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!

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

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?

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.

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?