Which audio software in background?

I think you shouldn't use type-inference in the examples, because it hinders being able to pick up the same concept in multiple places to reinforce it. Especially in the first example, there was an opportunity to clearly show that there's an int, then right below it, is how you declare a pointer to it.

I wanted to purchase your game on steam with source code. But i am not sure steam is providing source code or not. I can see that it's available on itch, but i don't want to use itch. Can you confirm if source code will be available in steam or not?

nice

Great lesson - playing around with the code and I see the passing by reference changes the value implicitly where as passing by value requires an explicit update to change the value - Being a real beginner to lower level is this something that is in your book and please can you do a video as it is a bit of a 'mind bender' for me: package pointers import "core:fmt" main :: proc() { number := 7 number_pointer := &number increment_number_point(number_pointer) fmt.println(number) fmt.println(number)// holds value number = increment_number_value(number) fmt.println(number) fmt.println(number)// holds value fmt.println(increment_number_value(number)) fmt.println(number) fmt.println(number) // doesn't hold value increment_number_value(number) // doesn't change value fmt.println(number) } increment_number_point :: proc(num: ^int) { num^ = num^ + 1 } increment_number_value :: proc(numb: int) -> int { return numb + 1 }

great feature, i wish more languages had it!

Clear explanation, thank you! Looking forward to the book. 👍✌️

If you don't mind, I have a follow up question: I see in C&O you have a World struct, I have similar for my project. Currently I initialize World in one of the "highest" scopes and then I pass a pointer to it down into pretty much every procedure since most procedures need access to some part of it, and making it global doesn't seem at all right. Does this pattern seem OK to you, how do you pass all your world state and display state about the program? My concern is that for a sufficiently complex world, I've got a huge world struct with all kinds of nested fields of various complex types that I'm passing down through every procedure. The knee jerk solution feels to just split the world up into several separate structs, but then you start having quite bloated function signatures as every part of the world will still be needed deep in the function stack. So either way it seems unwieldy as the complexity of the program grows. Is there perhaps a pattern where I can effectively "summon" parts of the world state I need on demand in any procedure without passing down a pointer to some massive struct, or avoiding the need to have every function sig's argument list get increasingly long in an attempt to chop the world state up? Thanks for the Q&A, and cannot wait to buy the book!

In my opinion, platformers or similar simple games should be released only on mobile devices, and complex games or games with complex mechanics should be released on PCs.

Cannot wait for this. The current Odin documentation just tells me nothing about memory management, it's only for people who are familiar with allocators and management strategies. I really want to move into a non-GC language but there's just zero understandable and practical introduction to the concept

Great tutorial ! I just want to discover Odin and this video is a good start. Thanks ! I just bought your game on steam, I'm looking forward to playing

For someone new to Odin, the use of ^ instead of * looks odd.

I'm going through core:io but I'm pretty lost with getting user input from stdin. Maybe you could please consider putting a section in your book.

Awesome channel! Can't wait for the book!

I loved smash it. So this is the artist huh? Wow. I just discovered tear down on KZbin and was intrigued by the physics which adds to an important realism which is fun and familiar. Just like the real world.

Thanks

Great explanations about memory leaks and a very clever solution to this problem proposed by the Odin language! Very interesting. Thanks Karl

Thanks Karl for the excellent video series. However I have to offer some alternative advice. There are many languages that disallow cyclic dependencies between packages (or modules, or namespaces depending on what the languages call their organizing concepts). Go, Rust, and Haskell, for example strictly disallow cycles, Java and Scala I believe may allow them but it's problematic. Same with the .NET family of languages. The problem of code organization and dependency management is mostly independent of language. What it takes is planning, forethought, and conscious, intentional design. If you're learning a language, working in a new / unfamiliar domain, or are simply not very experienced, you are probably not in a position to plan a large complex project very well, so you will have problems organizing (via packages) your code correctly right out of the gate. This is one of the most obvious advantages highly experienced engineers bring to a project - experience around large project code organization. Dropping everything in a single package/namespace is an easy "solution" because it effectively ignores the primary mechanism for code organization and relies on globally unique naming instead. This non-organization method of organizing code is useful for everything from toy projects, demos, and learning examples to smaller production projects run primarily by one person or a small team. Small games, command line utilities, wrapping existing libs from other languages, things like this are small enough that you may not really need to organize (via package/namespace) the code. Once you get into larger projects involving large / multiple teams and hundreds of thousands or millions of lines of code, you better have a well developed philosophy about code organization, and it will involve multiple packages with carefully considered interdependencies, which allows for sub-teams to work more independently (which means quickly), work to a "contract" (or interface, or API), isolate the impact of code changes, make it easier to build discreet and focused tests, and many other benefits. It's good do introduce these concepts early in a software engineer's growth, so that these concepts and practices become engrained early. Because you're right that code organization done wrong is worse that no code organization. But no organization (or minimal, ad-hoc, unplanned organization) is limiting in proportion to the size of the project and team.

Starting a C++ project is pain 😢.

Your contents makes Odin and low level programming in general less scary. Thanks a lot Karl ! Ill buy your book once it comes out for sure !

👍 great. But how do I run it in vs code?

One thing I recently learned the hard way while using pointers for the first time: if you accidentally let the memory that your pointer refers to get freed, then your pointer becomes bad (a dangling pointer), and now points to some random memory. The code might crash, or it might do something weird that drives you crazy. This confused me because I didn't understand the difference between a nil pointer and a bad pointer. At least Odin initializes the pointer as nil so it isn't bad to begin with (a wild pointer), unlike C/C++.

Thanks Karl. These short single subject videos are great. They are easily digestible which is especially important for subjects like pointers that are notorious for tripping up people new to programming. Keep up the good work.

Looking forward to your book!

Thanks for the video! :) Looking forward to your book. Quick question. With my understanding, if you pass a struct to a function (not as a pointer) it will make a copy of that struct, like a value type, yes? So should we always be aware to pass it as a reference, even though we might not want modify the struct inside the function itself? Or is it fine to pass copies around, if we're not modifying it. Hope it makes sense.

I just want to say a big thank you to you! You've really helped with me getting into and understanding Odin. I'm a go dev by default but have been having a blast with Odin, especially with raylib. Looking forward to reading your web book. 😁

what would be nice is a stack trace too. Knowing where the alloc is 50% but the other half is HOW it got there.