Man can you one day ract to the playstation 5 teardown? because now than the SSD M2 NVME PCIe 4.0 came out to the market thats makes you choose well you M2 SSD CARD, and which one are you going to choose

recompiling the kernel for the fifth time? -probably gentoo- reminds me of the gentoo user memes, i mean

Really appreciated this video, I never use c++ myself so I usually have to ignore some of the things I don't understand (assuming any) but C is so easy to understand which is why I love using it. As a side note I recently realised that the usual "do { CODE; } while (0)" trick that is used in macros would be better done by a simple "if ( 1 ) { CODE; }" which is easier for the compiler to understand and optimise regardless of how old the compiler is.

I loved the video. While there was lots of valid criticism, it did kind of seem more of a "review of how the code works" than an actual code review. Would be cool if you highlighted issues with the code and gave specific examples of why it's bad code and how to fix it.

Have you thought about trying out Rust (the language) for game development, and giving your thoughts on it?

thanx to you we've learned a lot too

Thanks for sharing the Code :)

I spotted a few bugs in your code: - when pressing L, % will not ensure that you won't go into the negatives (except if your value is unsigned)! (-1) & 5 is -1 - program.c, line 95: you probably meant + size.x, not + size.y. But it looks like you aren't really using that value anyways 😄 this splitting of work can be done easier by start = (i*width)/numberOfThreads, end = ((i+1)*width)/numberOfThreads. This is also less error prone (if you have numbers, where numberOfThreads * width < 2^31-1, if you're using 32 bit signed integers). Your work is then for(int x=start;x

When you comes to the point of naming your vars as "this", it's time to go C++ .. And for god sake keep it implicit.

what did you find most usefull?

So no credit to the author for writing fairly clean code in order to facilitate easier debugging?

Kudos to both of them honestly. Cherno picked up structure super quickly, but it was in part because the program was structured fairly clearly.

@@Borgilian sure, credit to the author IF he made a project that didn't have to be debugged as soon as you downloaded it

@@MPG42 Other than the images not being in the assets folder, it was probably partially due to a diffierent compiler being used.

@@LittleRainGames malloc'ing an additional byte at the end of a char array, not writing to it and hoping it happens to be zero is a bug.

Pretty sure many old programs did just that and flipped it back for display. For ray casting I remember that some rendered one column at time from near to far. This way you jumped to next pixel and started at same distance. (Have no idea if it was optimal though..)

@@pottuvoi2 Not entirely sure what you're considering "old", but in the context of the program presented, the 7 worker threads are writing column data into a texture, and then that texture is slapped onto the screen using OpenGL, while the original VoxelSpace (tm, sic) code would have been drawing straight to the frame buffer, which means drawing vertical lines means trashing your cache, as the frame buffer is row-major (rows are contiguous in memory). Since we're drawing to a texture, we can rotate the texture such that vertical lines go into rows of the texture, and thus contiguous parts of memory, and better cache performance. We then upload the texture to the graphics card (which is slow, regardless of orientation) and then render the "frame buffer" fullscreen quad.

@@DaveLeCompte Was thinking DOS era from 486 to early Pentium, when we had the usual voxel landscapes and tunnels. (Tunnel being the classic landscape render to array and then make it to tunnel with precalculated indirection UV map.) Sadly I do not remember if we did the flip when writing from array to framebuffer, but I know some did. There were fun tricks people did during those times, like framerate independent screen flashes by changing palette every refresh.

i was expecting some sort of marching cubes implementation, rather than a heightfield.

@@DaveLeCompte The "big days" of voxel space and related engines were the mid-1990s, where caching wasn't very important; drawing to the frame buffer meant a major bottleneck no matter which way you turned it. The first game with one was of course Comanche, and there were others: _Terra Nova: Centauri_ IIRC, _The Outcast_ and as one of the most recent, _Thunder Brigade,_ still in the 1990s. All of these could run well on a 300-MHz PII, if not always on max settings. Numerous demos had their height field segments, among them of course Future Crew with their uber-demo _Second Reality,_ but also the year before that with either _Unreal_ (unrealated to the game) or _PANIC!_ . Others followed suit, like the well acclaimed _dope_ in 1995 and the less known _Optic Nerve_ which at least IMO looked best. Since then, "voxxels" have appeared even on home computers like the Amiga 500, the SNES IIRC, and the ubiquitous C64. They're usually quite coarse and/or cheat with geometry (not allowing for rotation, distorting the terrain significantly, or otherwise providing a view that's very restricted or visibly unrealistic), but all of them check the "something that model was never meant to do" box.

It literally says in the email, make run_main.

I wonder if you couldn't perhaps do it horizontally instead and just draw the final quad rotated 90 degrees or something.

I did this as well, right after university. The idea was to have a futuristic city that mechs could fight on. I ended up abandoning it after getting obsessed with not wanting to draw fully occluded bars and wanting smooth rotations of the map. (Just imagine if I had put off optimization until the end.)

VoxelSpace is just name given by Novalogic to their engine. The tech is mostly just 4dof heightmap rendering

@@PiesliceProductions Voxel Spacing was the name in the demo scene

> draw vertical bars of a certain height from back to front That works, but slowly. I did the opposite and drew them _front to back._ For every pixel column on screen, I kept track of the y coordinate of the top pixel so far. I then computed the y coordinate of the pixel in question in 3D projection (easy if you don't tilt the camera up/down), and the x coordinate of 0.625 times the width to the left/right (fudge factor may vary). Then I worked one column at a time, skipping the column if the y coordinate is higher (i.e. the pixel is lower) than the terrain that's already been drawn. If it's not, you fill the difference in and update the y coordinate. The major hassle is the traversal of the array depending on what way you're looking. You want to do it line by line (a "line" being the direction where the z (depth) coordinate increases slowly) in order of increasing z, and within each line, you do it in order of increasing z too. That ensures proper overlap resolution. "The" _Voxel Space_ algorithm did it differently; it basically cast a ray (or a vertical stack of rays) and checked which terrain squares it flew through/over, generating one column of pixels per line of y values (rarely a literal line inside the array of y values, but a slightly zig-zagged path). It plays nice with cache and skips the x coordinate calculations, since only the relevant squares are hit by the ray cast, but it hits the closest squares repeatedly -- which isn't THAT bad, since the total # of intersection checks is still bound by (# of pixel columns) * (draw distance in square diameter) * (fudge factor close to 1) per frame.

I'd easily have watched him mess about with this for an hour or 2.

@@Bobbias Same here!

Exactly. I think there's a youtuber called javidx who writes entire games on the console -- _without_ shader code. When he mentioned shader code, I thought "the WAT now?" because I've written something like that (well, let's say 50% of that) in both DOS and Windows. The DOS version handled a few special cases like terrain exceeding the top pixel line (which the demo shown here at 07:36 does NOT, or at least doesn't demonstrate) or the player submerging in water. The Windows version was simpler, basically what we can see here minus the coloring that's very close to Comanche, and it couldn't view the terrain at an angle either. I got 15fps in DOS in the 320x200 mode on a 486-50 (although I used the ultra-coarse mode, which only drew 80x200 pixels - Comanche could switch between that and 160x200 and was a bit faster). The Windows version could go full 640x480 with similar performance on an entry-level Athlon. Both 100% in CPU, no shaders added, or any 3d hardware for that matter. So, to someone who tried to recreate height field (or "voxel space") engines, that felt a bit underwhelming, like "You did 20 in a Model T? lel n00b, I did twice that in a Ferrari!" But not to belittle OP, *making that 3D engine was a solid piece of work,* even if "120fps at full HD" feels rather mediocre to me if done with a shader (which IS a dependency if you think about it). I'd like to see _more_ of that engine. For comparison, the DOS version had a 256x256 map, a primitive HUD of sorts, covered the top half of the screen with landscape and part of the bottom half with a minimap; I wrote it in Turbo Pascal, then the most popular choice among amateurs. The Windows version was written in Visual C++ 6 and far more primitive overall (no causality here), but used real geometry, indistinguishable from a triangle mesh, not the coarse approximation of the DOS graphics. It looks like I lost both sources over time, so there's only my word that remains, and memories of evenings spent to code that thing, test it, and reboot my PC countless times because I wrote the inner loops in Assembler.

Render it sideways you mean? For cache performance?

take a look at a game called Teardown, it's a blast

That's how I felt about the first 3d artillery games that tracked terrain damage (I think "Blast Doors"). It was a very simple predecessor of Scorch3D, which is worth checking out, too (free). > it's a blast Very _punny_

Yea I saw some nice voxel development channels on KZfaq but never got myself into the matter. Thought Cherno could be a good teacher

You can blame Nova Logic for that one; they trademarked it under the name "Voxel Space." And if you were in high school when Comanche came out, you probably had someone in your class who tried coding that stuff himself -- or _you_ were that one. And more than one who claimed they did it on an Amiga / C64. The sort of guy who never invited anybody -- for Reasons(tm).

You could say they are voxels and render them as such too if you wanted. It’s just a rendering optimization that makes them feel like they’re not voxels, but nothing in the data says they’re not.

Doom 1993 used rotates textures for rendering columns. Works in practice

Agreed. I love voxels for seemingly no reason. I would love to see something other than cubes at some point, such as tetrahedral voxels. With only 4 faces in total and all acute angles they could be quite interesting to model with.

What did you learn?

@@climatechangedoesntbargain9140 Martial Arts

@@saulgoodman5662 how the climate always changed and how nuclear energy, instead of in efficient wind turbines is the way to go.

I guess it's easier to admit when you work in game engine development given how DirectX is windows only (officially)

OS shaming is terrible. Also with my colleagues I pretty much cannot mention that or the fact I am coding with C++, they only accept Rust and everything else is an idiot to them.

@@Mystixor Is Rust good?

@@martinjakab It is a powerful programming language but the lack of support and libraries makes it an easy choice for C++ for me

@@Mystixor I thought about learning Rust, because I heard that its similar to C. How much is it true?

*Bresenham

Storing the data column major would do the trick (as is preferred by many linear algebra libs, e.g. Armadillo, BLAS/LAPACK, Eigen)... I'm saying the same thing really but we can do it as the data is loaded and just once if we don't load with the image lib.

*syntax

As game developer you spend 99% of your time READING code and 1% WRITING code. The best way to get good at reading code is to ... you guessed it ... read code.

@@MichaelPohoreski true for just about all types of developers i guess. (take that from an automotive embedded guy)

@@urugulu1656 Good point!

The sprite struct is not that big it is a pointer + elementCount + size This is not c++ with copy constructors

Yeah especially on Windows, the CreateThread function is very expensive, I'm shocked that he was getting over a 100 fps and rendering the entire scene in about 1 second whilst spawning 7 new threads (and presumably destroying the old ones otherwise he'd run out of ram) every frame. Maybe pthread_create is cheaper ?!?

That's on Windows. I'm pretty sure Linux actually uses an underlying thread pool or some other funny optimization like that, so there is not much overhead from creating and destroying threads repeatedly. Keep in mind there were ~1000 threads being created and destroyed per second *while they were also doing the rendering work!*

@@chlorobyte_projects I'm sure Linux does not do that. Yes, the spawning of threads is a lot cheaper than on windows, but threadpools are common on Linux as well.

Not sure how the work the shaders do compares to the output bandwidth... Let's play devil's advocate and say that a ray crosses N boundary before hitting the landscape. That's N reads from the height map per pixel written. This doesn't look like it would affect performance a lot, unless you're directly facing a cliff or something -- and in this case, where N is unusually small, the FPS would be at its highest. It could well be that poor pixel generation order isn't affecting FPS for any sensible FPS value, but only the theoretical _max_ FPS in an abnormal setup. That might occur if the player character has crashed and even act as an unintended FPS limiter now that I think about it...

That I agree with (not too difficult to copy the assets folder into the bin directory), but the lack of null termination character??

@@TheCherno I caught it right away having done similar in Vita homebrew project. Most times it works okay until it doesn’t ;)

@@TheCherno Yeah the null termination thing was weird. I just find it strange that something like that would slip through on the branch he sent you. I mean if he would have run it in that state it could not have worked. Unless there was some other magic going on with that make command

@@TheCherno I think he is zero-ing his memory in a bad way ({0} instead of {}) that maybe works on his environment but not on yours, so his buffer was null terminated but yours wasn't.

@@darkfire2703 it may work for author, because he may have slightly different setup. Like different policy of kernel about heap memory, maybe zeroing it for him due to security reasons, or different compiler version which does that, etc... there's lot of security work on modern OS to prevent leak of data between processes, either clearing or randomizing memory content, so you can't just easily allocate or physical memory and rummage through old data of other apps. It's a bit painful to watch if you did grow with 8 bit computers and you understand all the extra costs involved, but that's the state of the world we are living in, even memory content has to be randomised by OS now... Anyway, author could have used calloc in this case to ensure that whatever is read from the shader file is the only non-zero stuff, even in case the file is loaded partially, and not up to the expected length.

Having run a Gentoo setup on a laptop in like 2004 or something, I've seen Linux break in some horrifying ways. Linux experience varies depending on lots of things. Keep in mind I love Linux, and am running a windows insider build with WSLg. Gaming in Linux just is not on par with windows yet, and I've been using windows since win95, so it's always been the default.

@@Bobbias I mean, using Gentoo or Arch, specially older ones, is asking for trouble. I used to use Arch because I was a kid with too much time... And fixing the graphical interface every week was normal. With Ubuntu LTS the most exciting thing is installing it the first time

@@Bobbias While gaming on Linux will never be quite as good as on Windows, it has improved significantly lately.. and should improve more when the steam deck comes out

@spaceLem Yeah, I've tried it and it's nice, but I'm staying on Ubuntu LTS, I've messed about with instability for enough years

@Fluxx Different tools for different users; I don't agree with your statement but it's just an opinion at the end of the day.

Also global structures is a huge code smell for a lot of people

You've been infected with this terrible virus. It's silly to make a program way more complex than it needs to be, to not only be able, but literally be forced to test it. Just think your programs through, use proper design patterns, and use tests on specific parts, where you can't be certain something weird won't happen. Most of the time it's way more useful to test complete use cases, where having parameters is irrelevant. Unit tests are so over rated.

@@TheAxeForgetsTheTreeRemembers I keep bumping into code which was well thought through, done with proper design patterns, and tested over specific parts, having ton of bugs... it's like pattern, I just look for values/configurations not tested, and unearth subtle off-by-one or doesn't-expect-zero or didn't-expect-that-previous-thing-ended-in-that-second-state I did recently receive 3 line change patch for one open project with comment "I did test it manually, no need for unit tests, it's very simple change" ... and yes, there was bug in it, not accounting for one type of input data. (and I did knew before I released the SW, because I actually do have unit tests for that particular function, so I knew 5 seconds after applying the patch that it did break something it should not have).

@@theoneandonly1833 but this "globals are bad" is kinda overdone, global variables make sense sometimes. But the implementing code should probably take some initial pointers, even to globals, to cater for both easy testing, and not hiding globals behind fancy names like singletons and similar.

@@ped7g A program is likely to have bugs, tested or not. There are plenty of softwares out there that are well tested but still have bugs. Some of them being critical, yet completely overlooked by improperly thought out test suites.

I'm pretty sure all the MMX, SEE, AVX, AVX2 and AVX-512 Intrinsics in immintrin.h work with C99, possibly C95. They are all just C functions which correspond to compiled assembly. This type of work load should fall under the term "Trivially Parallelizable" and it ought to be quite simple to speed things up by an order of magnitude using SSE instructions. I should note that "Trivially Parallelizable" does not mean that the compiler can figure it out, it just means that the data doesn't depend on other data like "c = a+b" and thus you can divide an conquer very easily here. The compiler likely hasn't auto vectorized most of this code because it's too complicated for it to figure out, mainly because there are conditions which are almost never simple enough to auto vectorize. Calling functions in loops and using 'break' will also pretty much kill auto vectorization. For authenticity one could stick to MMX which was available in 1997, but lacks floating-point support, only byte and short integer , for floating-point math you'd need at least SSE 1999, for 32-bit and 64-bit int you'd need SSE2 (2001). Some highly optimized instructions from SSSE3 and SSE4.1 could also be helpful but those are from 2006 and 2008. These days AVX and AVX2 are faster, easier and pretty commonly available. Side note: On Intel the MMX instructions have been intentionally downclocked for about a 15 years now to encourage developers to use at least SEE instructions. MMX instructions typically run at 1GHz I believe. So while not officially deprecated like 3DNow! is, MMX in widely discouraged.

@@Dave_thenerd thanks for the information, I've never delved into SIMD stuff in any language, I'm vaguely aware of the concept, but none of the details. And I have never really written any pure c at all.

Interesting. Does that mean the data isn't copied? (I'm a C++ guy, very ignorant with regards to C). In this program a copy would seem undesirable.

@@superscatboy There is a copy of primitive values from stack, including pointer. But copying those is very very cheap, even in C++ it's not advised to pass ints by reference right? You just do void func(int x, int y) not void func(const int &x, const int &y). Now, since in C structs are pure POD and nothing else, compilers have easy time optimising those as long as you won't create oversized buffer on stack. So if you have such struct in C struct Point {int x, int y}; then it's better to pass it to function by copy void func(Point point) cause all what happens you copy bunch of primitives void func(int x, int y) which is cheap. If you pass it by pointer then you're introducing indirection level which is never free and you pay for it every time you dereference, for simple copy you pay only once.

I would actually also make Program this a global variable. But that is considered a bad practice by OOP gurus, uni professors, corporations managers, and other people that have never written a real application.

While I'm pretty sure that was a joke, it *is* possible to recompile the kernel. It just takes 800 million years to do so.

It was just a bad joke that was probably not understood as such by 80% of the viewers.

Both SSBOs and MFLAs (modern four letter abbreviations) actually ;P

It's typical undefined behaviour, that's why it's so problematic. Basically that last character will have whatever value just randomly was in the RAM before. 0 is probably the most common value in RAM, so it will work most of the time but not always. There can be exceptions to this, as some debuggers can initialize those values but under normal code execution i's undefined.

1 is a magic numer. 1 why?

@@Henry-sv3wv Null terminator. Not really a magic number, if you're seeing a char array allocated with one extra element it's fairly obvious

@@ciekce ah, ok. yea i realize that +1 is also often done in code

You don't have to compile the kernel on Ubuntu or Arch either, that must have been a joke

@@chlorobyte_projects don't know about that, on arch I had to make some changes to the bios configuration because of the processor, gfx card and motherboard, fortunately there was someone having the same problem in the arch forum. The best thing was that he had the same processor, gfx card and mother board. The final solution was just to add some flags to the init command of the kernel, something like amd_soft and another flag

@@lmtr0 still not compiling the kernel lol

@@chlorobyte_projects yeah true, have you tried Gentoo??

Copy elision wouldn't work with passing a struct as a function parameter, unless maybe the function is inlined and it doesn't change the object. It's also not really a thing in C, but I'm assuming compilers implement it as an optimization anyway. RVO is already used with programCreate(). I agree that using globals is not great, but passing pointers to the struct instead of the struct itself by value would still be an improvement.

I'm pretty sure it depends on the architecture of the cpu and other factors. Even if it is 1 across all the architectures, it's a good practice to be safe

@@rutvikpanchal5726 still, 1 * is completely unnecessary

@@user-dh8oi2mk4f ohh yeah lol, didn't notice that at all, I was so focused on size of char

sizeof(char) is 1 by definition in C. The number of bits can vary (see CHAR_BIT), but one char is required to be 1 byte. There is no C implementation that was, is, or will have sizeof(char) being anything other than 1.

It's considered good practice like this in many conventions I believe. A good compiler will optimize it away anyway.

Not for a structure that you only ever have one of. It’s equivalent to a singleton in C++.

@@mitchlindgren not really, by passing it around to where it is needed I can be sure that the data is not modified in an unexpected way, i.e. only functions that I pass the struct to can modify it. But if the data is in global memory, or if it is in a singleton pattern, there is no such guarantee. You are wrong that it is equivalent with a singleton in C++. A singleton in C++ usually comes with a mechanism to ensure that there exists one and only one instance of the singleton, either that calling new more than once throws and exception or that only the first time creates the object and then all subsequent calls returns pointers to that object. Encapsulating the data in a structure that then is passed around is not a singleton pattern.

Thats why I functional is better most cases

@@tordjarv3802 "Encapsulating the data in a structure that then is passed around is not a singleton pattern." If you're always referring to the structure using a global, you don't have to pass it around everywhere. I'm not going to get into a debate about functional vs. imperative programming, but keeping single-instance structures global memory is common in C and there's nothing wrong with it if done judiciously.

@@mitchlindgren The point is that you should not pass it around everywhere. If that is what you doing your code do not have proper separation of concerns, and is flawed by design. In principle there should only be three methods that gets it, init_main_program , run_main_program and finalize_main_program, no other methods need to have access to all data in your program (if they do they do not follow SRP). Also, as part of my PhD I have written alot of C, I know what is bad design and good design, and a global mutable states is a bad idea since it kills extendability. Part of the project I have been working on includes a C code written by a prior PhD-student, and it is riddled with global mutable variables. It was originally single threaded (still is) but we needed to run parts of it in parallel because it was extremely slow for the new application. The only way to "parallelize" it (since every part depended on several other parts in non trivial ways) was to add command line arguments to be able to tell it which parts of the calculation to do, and then launch separate instance doing different parts. This of course implied that it had do the full initialization for every new process.

Just because code doesn't have comments doesn't mean it's difficult to understand. If anything, the more comments your code requires to understand, the worse your code is in general.

It's okay, steamos 3 will be out by then.