Відео

i might not have gotten to all comments ( didn't) but thank you guys for watching and if you have questions comment here directly. actually doesnt matter i see it anywhere

Listen guys I'm stupid I'm new to all this crap I just come from your average game engines... I wanna ask in terms of sprite switching... why not just make a file for each frame of the sprite put in them in an array and iterate between them... yes this might be a logical error on my end I want you to correct and tell me why its wrong, thanks in advance.

when i was writing c++ for a project, it felt the same. there are a bunch of different ways to do the same thing and it made me waste time trying to find out "what is the best way". eventually i gave up, just used the one which looked most intuitive to me, and then wait for others to criticize/fix it.

try C3 :)

Bro u went from baby toys to what even companies are scared to use lol. Should had used monogame with c sharp. Performative snd scaleable.

Rewrite it in C

Assembly and C are all you really need.

thank you, very good video, but please get a better mic or make sure you have the mic's volume down. it's peaking a lot

Not to be that guy, but I see no point in going C if you are building an indie game, no matter how much effort you put, you won't hit a performance ceiling that easy. I would worry about getting productive to ship fast rather than worrying about the edge cases where you can't get around performance issues with python.

"I switched from a blimp to a car"

I switched to lua to C++

Respect

Now that you've switched to C, can you call yourself Joe Buffer?

btw C uses automatic memory management in the way of the stack, if you want to actually do low level programming make a full game in assembly :D

flame bait: Going back from Python to C or C++ is like going back from AR-15 to 1880s single shot rifles, "just cause they're easier/faster to manufacture". C developers should really get out & admit they're just copying their neighbor's code & acting like they understand it 😂

flutter >>>>>

TL;DR at the bottom. C being close to "the hardware" is a misconception. C has no idea what "the hardware" is supposed to be, and it comes with its own set of assumptions and it has its own rules and set of operations, collectively known as the C abstract machine. The C abstract machine is what is specified and standardised in the ISO or ANSI C standards. Verbatim, the C standard states "The semantic descriptions in this International Standard describe the behavior of an abstract machine in which issues of optimization are irrelevant." Your C compiler's job is to take a valid standard C program, determine what abstract machine operations it performs, and then translate that to the given compilation target. Compilers make the assumption that your program is valid, i.e. all operations it performs exist in the C abstract machine, otherwise known as not containing undefined behaviour, and optimise them based on this assumption. C inherited much of its worldview/memory model from B or BCPL, ultimately, most types are thin wrappers over "int" which is the everything-type, essentially (used t. If you look at old pre-standard C (otherwise known as K&R C) you'll find types are completely optional, just like B and BCPL. The automatically assumed type as always "int" because that was almost certainly what you wanted. You'd only really want "char" for strings otherwise. As long as your program is valid and the compiler doesn't contain any bugs, it is free to "mutilate" your program in any-which-way it pleases to get you the best runtime performance, as long as (observably) the outcome is the same. Assembly also is not safe here; the CPU itself actually does the same to help you out even further. Modern CPUs turn your code into something completely unrecognisable before actually executing anything, for example: For compilers: 1. Redundant operations are removed 2. Load/store pairs are removed 3: Compilers are capable of somewhat primitive malloc elision and optimisations around dynamic memory allocation 4. Compilers can inline functions into each other, outline common code snippets into functions, roll or unroll loops, autovectorise loops 5. Functions can be prevented or allowed to cross page boundaries depending on how often they are called 6. Compilers can use profiling information to derive hot/cold or likely/unlikely functions or branches 7. Cold branches can be tossed to the bottom of functions to keep hot branches in instruction cache near the branch instruction 8. The "strength" of operations can be reduced by a compiler, transforming a more expensive operation to a cheaper one, such as expressing multiplication or division through bit-shifts with immediate values 9. Compilers can move code out of a loop if it results in the same value each time 10. Compilers can use constant folding and eliminate redundant calculations 11. Compilers can replace expressions with the result evaluated at compile-time 12. Compilers with target CPU information can reorder instructions to tailor to how the pipeline of said CPU is designed 13. Compilers can swap or eliminate nested loops to reduce branching for the CPU to keep track of and result in a more predictable memory access pattern For CPUs: 1. Handling of instructions is pipelined, fetching, decoding, and executing are interleaved. 2. Instructions are actually macro-operations, and certain macro-operations that fit a pattern can be fused or transformed to something more efficient. 3. Macro operations are converted to micro operations, which actually direct the CPU to perform things. 4. Certain micro-op patterns are also detected and converted to more efficient ones. 5. Micro-ops are reordered and scheduled to better utilise hardware and expose inherent parallelism, modern CPUs can have reorder buffers as big as 512 micro-ops. There is duplication of hardware such as ALUs, often with different capabilities to save on silicon (not all ALUs are created equal and support the same operations) and micro-ops are dispatched to execution ports. 6. Small and tight loops are detected and stored in a special cache buffer so that the micro ops for said loop are always quickly in reach. 7. Data dependencies and hazards are identified and the CPU maps architectural registers to actually physical registers which vastly outnumber the architectural ones to better parallelise the workload. This is called register renaming and the mapping is kept in a register alias table. 8. Branch history allows the CPU to detect branch patterns and make predictions to execute a branch speculatively before it is actually reached and to prefetch all the data it requires. IF that branch is taken then the instructions executed are "retired" (committed), else, results are discarded, and through the branch order buffer the CPU state is rolled back. Branches that still have not been retired are known as "in-flight" and modern CPUs can support tens of them. 9. Accesses go through load buffers and store buffers to merge them and use less bus. 10. Load/store pairs can just be directly forwarded, so a datum that is stored to memory or a register that another visibly loads later can be directly transfered in-CPU without touching any registers or memory at all. 11. Data dependencies can be resolved in-pipeline to bypass what would normally be a pipeline hazard, for example an add instruction's result can be forwarded directly to a conditional jump that follows it that has just been decoded, essentially passing the data forward in time. 12. Although Intel is phasing this out because it's somewhat stall (wait) dependent, CPUs can perform simultaneous multi threading, issuing (allocating) instructions from more than 1 thread in 1 cycle where the 2 threads execute on the same engine (ports, ALUs, etc) but hold entirely independent state (register file, etc). 13. Data is prefeteched for predictable memory access patterns to make sure data are available Note: The mentioned techniques are actually really old, and the list is not comprehensive. IBM has been using these since the 60s in their large machines (giant mainframe rack, probably liquid cooled, if you add the punchcard reader, numerous tape drives, teletypewriters, etc it is truly a room-scale setup), and they began coming to microprocessors in the 90s. TL;DR: Nobody is really close to the hardware on modern high-performance CPUs since the early 90s, not even assembly. The compiler (if any) and the CPU are mutilating your code beyond recognition no matter what you use. The final "program" that is executing is not necessarily performing the same operations, at the same time, in the same order, on the same data, as what you wrote, it only has to appear that way, and when it doesn't appear that way and is observable you get things like Spectre and Meltdown.

my story is the same as urs, I also started to create games using pygame but found the reality. So I switched to c++ and now making games with OpenGL in C++

You have died but reborn

If C and C++ ever get a modern easy to use package manager they'd rule the day I swear.

Sincerely, knowing a lot of languages is better than only knowing one. I think learning one or two really well is the best. But being able to at least read various programming languages is better.

As a primarly a C++ programmer if I were forced to learn a new lanuage it would problaly be GO because it straight forward and its comunity doesnt suck like the Rust comunity.

Python is a toy scripting language for writing small programs??? Bro, the place you have put this video is written in Python.

1:02 i recommend Sdl2 as it is faster

"I switched from a mountain bike to a race car"

now rust is waiting for you

i feel you setting up raylib on linux 💀I was using macOS with XCode and the setup is so cooked 💀if not worse than doing it in linux

The book he shows is "C++ Programming: Program Design Including Data Structures , 4th edition , 2008". Maybe not a good book for C++.

NICE ONE LOVED IT

Just so no one watching this gets the wrong idea, you can write OO code with C, it's just that the language has nothing built-in to facilitate doing so as easily as you can with a language like C++. That's not necessarily a negative unless you really want OO for everything, which you really shouldn't anyway. Also, if anyone is thinking of getting into programming with C based on this video, heed his lesson about understanding how the build tools work, how to specify libraries and include and library paths. Also also, learn the basic technique of C-style namespacing by prepending what you want to call your library or module to the front of all the functions you write for it, like mylibrary_myfunction. Don't pollute the global namespace like RayLib does..

Traitor. Stick with Python.

I recently setup a project using flecs (ECS) raylib, nuklear (UI), box2d (physics). I was initially going to use SDL3 GPU instead of raylib, but I find that raylib is the abstraction level I was looking for (I may dig deeper later) - many people will knock it (and I prefer Meson myself) but dependencies are so much easier using CMake and git submodules - well worth spending the time to get setup.

Now you speak the language of the gods

This is a reupload from a video 5 days ago because I messed up the audio.

Amazing Video, keep it up.

Sweet tutorial, never knew about the embedded terminal. May need to rethink my Tmux setup.

But, if you are an expert in C++, you are also an expert in the computer.

But doing it in C and not learning what C++ provides, makes you reinvent the wheel all over again.

"You know how the computer works if you know C" No. You know how PROGRAMS work when you know C. If you want to get low into the hardware, it is best to know ASM.

i very much agree, when i have to code in usermode i usually use C++ because it is faster to write programs that do not require a direct almost 1:1 translation from code to asm, but there's no way i would use c++ for a kernel mode driver... C is way better than C++

Same for me😢

Great video and a valuable testimony to C's simplicity! Maybe another point to consider: If you stretch yourself a little bit as a more or less average (meaning: non-super-genius) programmer, you can come up with your own C-compiler. This is not true for C++ (or any other more "advanced" language), where you have to be a genius to even understand the language, much less write a compiler for it. Nowadays, many people don't care about how compilers are written, but this creates a dependency on what is given to you upstream that I find uncomfortable.

Ok but how can i create all the object oriented stuff without java keywords like class and new? The legendary C programming book does not teach us game dev through C 😢

Nand to Tetris is a lot of fun!

how do you handle exceptions in pure C?

try to compile c with zig cc

just a heads up. while that song likely is public domain, its performance/recording might not be. and, a general advice. I recommend stop criticizing things you clearly have very little experience with. it's a sign of arrogance. while I agree that C is better than C++, your arguments aren't great, and your code is has several beginner mistakes.

"There's not too much to C" - ooft, I have the first ed of K&R book on C, and it's even less pages than your copy: but as you dive in there's most definitely a lot more than meets the eye.

Hey there! You have a perfectly 32 comments sorry for ruining it :( (you can delete when you read this or keep it when you reach 64 so it evens out!)

As an aside I recently discovered that you can do memory management in C without needing malloc (or an OS function like mmap) at all - all you need to do is in your main.c create a global char array for the number of bytes you need, and then pass this as a void* to your own custom allocator (I'd suggest either an Arena/Linear allocator, or a free list allocator - google "Ginger Bill Memory allocation strategies" to see how to create them. The advantage to the global char array approach is there is no limit from the C language on size, and it is automatically cleaned up when your program ends - the only disadvantage is you need to know the upper maximum amount of memory your program will need.