importing structs with @import

[cosmic saffron]

ZLS isn't recognizing anything from a struct I'm importing from another file. Am I importing wrong? Am I getting the path wrong?

main.zig:

const GameInstance = @import("src/engine/game_instance.zig").GameInstance;

game_instance.zig

pub const GameInstance = struct {
    // PROPERTIES
    window_width: i32 = 800,
    window_height: i32 = 600,
    is_fullscreen: bool = false,

    // MAIN FUNCTIONS

    // creates the GameInstance object
    pub fn create(self: GameInstance, width: i32, height: i32, title: [*:0]const u8, fullscreen : bool) void {
        self.window_width = width;
        self.window_height = height;
        self.is_fullscreen = fullscreen;
        
        raylib.InitWindow(width, height, title);
        if (fullscreen == true) raylib.ToggleFullscreen();
    }
  ///...

[young portal]

I mean firstly, does it compile?

If it does, you're probably not doing anything wrong with the import

[last silo]

uh oh src/engine/game_instance.zig screams incorrect path

imports are relative

i imagine main.zig is in src

thus it should be engine/game_instance.zig

[young portal]

sounds correct to me :)

[cosmic saffron]

src\main.zig:2:30: error: unable to load 'src\src\engine\game_instance.zig': FileNotFound
const GameInstance = @import("src/engine/game_instance.zig").GameInstance;
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[young portal]

Yeah so it should be engine/game_instance.zig

Like auguste said

[last silo]

btw heads up, if that game_instance.zig file only has GameInstance in it, you can just remove pub const GameInstance = struct { and }; and rename to GameInstance.zig (files are implicit structs!) and then import that directly

[cosmic saffron]

oooh ok

[cosmic saffron]

how do you do self though? because there is no GameInstance class for it to refer to now

[young portal]

const GameInstance = @This();

[last silo]

sniped :v)

[cosmic saffron]

also, the compiler gave some sort of error when trying to change window_width that it was a constant and couldn't be changed, but window_height didn't throw an error?

[young portal]

You probably want to take a pointer to GameInstance

So pub fn create(self: *GameInstance, ...

[cosmic saffron]

now it's saying one of the functions aren't a member function?

[young portal]

what's the signature of destroy?

[cosmic saffron]

yet it's right here

// destroys the GameInstance object
pub fn destroy() void {
    raylib.CloseWindow();
}

[young portal]

Add _: GameInstance

You can't call it on an instance if it doesn't take an instance as a parameter

[sacred kelp]

or Self

[young portal]

Self isn't defined

[sacred kelp]

I mean GameInstance

[cosmic saffron]

so are functions without _/self : GameInstance a static namespaced function?

[young portal]

Exactly

If it doesn't take a value or pointer to the instance, it's not callable on an instance

[thorny dew]

All functions in Zig are namespaced.

[young portal]

So you'd have to call it as GameInstance.destroy()

[thorny dew]

There's no 'actual' member functions here; only sugar 😛

[young portal]

(btw you can call "instance functions" like that too: GameInstance.create(my_game_instance, ...))

[thorny dew]

[x.f() -> @TypeOf(x).f(x), or .f(&x) if necessary]

[cosmic saffron]

YES
THE STRUCTS ARE WORKING

tysm
i've been trying to migrate everything to their own structs so i can keep track of some values as well as do other stuff than init just raylib

so

how to remove the = GameInstance {};? i want the create function to be able to initialize the game_object variable on creation, i want to avoid null-initializing stuff and then setting the values

var game_object = GameInstance {};
game_object.create(DEFAULT_SCREEN_WIDTH, DEFAULT_SCREEN_HEIGHT, "h", false);

[thorny dew]

You can either

1. Make an init that returns a GameInstance (and then do var game_object = GameObject.init(...);)
2. Make a create that allocates a GameInstance, and returns the newly allocated pointer.
3. Make an init that takes a *GameInstance and initializes it - which is basically what you have already.

[cosmic saffron]

so with option 1, would i replace

self.window_width = width;
self.window_height = height;
self.is_fullscreen = fullscreen;

with

return GameInstance {
    .window_width = width,
    .window_height = height,
    .is_fullscreen = fullscreen,
};

?

[cosmic saffron]

nevermind it's a yes
anything i'm doing "wrong" in my current init function, like any bad practices?

// creates the GameInstance object
pub fn init(width: i32, height: i32, title: [*:0]const u8, fullscreen : bool) GameInstance {
    raylib.InitWindow(width, height, title);
    if (fullscreen == true) raylib.ToggleFullscreen();
    
    return GameInstance {
        .window_width = width,
        .window_height = height,
        .is_fullscreen = fullscreen,
    };
}

[polar spade]

i think it is weird to keep that state when raylib is already keeping it for you

bad practice: duplicated state that needs to be synced

[cosmic saffron]

hmmm
would raylib.isWindowFullscreen() have a higher perf cost compared to storing the value? or do both methods cost the same?

[sacred kelp]

I struggle with these kind of questions too

[young portal]

read the source

[polar spade]

https://github.com/raysan5/raylib/blob/17c443ee6db0a111d111e766bb517657204c3574/src/rcore.c#L1125

yeah read the source

in general

[sacred kelp]

I guess that is one solution.

I was gonna say that seems like a premature optimization.

[cosmic saffron]

idk if returning a val from a function would have a higher cost than just reading the value from memory
would the compiler automatically convert it to just reading the value anyway?

[young portal]

that too

In most situations yes, in this situation probably not

So there'd be a tiny overhead

[polar spade]

this is a once per frame thing at worst

[young portal]

But I wouldn't worry about it

[polar spade]

if there is a difference it's going to be negligible