Thanks for watching, hope you guys enjoy this series as much as I do! ❤️ Don't forget that the first 1000 people to use the link will get a free trial of Skillshare Premium Membership: skl.sh/thecherno05211
Yeah, he has to be doing some linker logic - which includes compression, no doubt - to get it down below 4KB on Windows. Because, in fact, Windows automatically wastes 4KB for DOS compatibility on every single ".EXE" file. If you open an ".EXE" in a hex editor, then the first two bytes will be "MZ". These are the initials of Mark Zbikowski, the coder at Microsoft who created the DOS Executable format - he just used his own initials as the file's "magic number". Then you have the DOS executable header and, within that, there's a "pointer to New Executable". This actually points to the Windows executable (the format of which has changed over time, as the first Windows format was "NE" - new executable, hence why the field is "pointer to New Executable" - but that's from the old 16-bit days, and there's a "PE" - Portable Executable - used from the WIN32 API, that is Windows 95, onwards and there is a 64-bit revision of PE, which is much the same but, like, expands certain fields to have 64-bit width). So, tacked onto the front of every executable (and we're not just talking ".EXE" files, because pull up ".DLL" files or ".DRV" files in your hex editor of choice to see the "MZ" bytes that confirm that these essentially use the same underlying format too), is a functioning DOS executable. What does this DOS executable do? It prints "This program requires Microsoft Windows" to the console and then exits. Yeah, that message does not actually exist in MS-DOS itself, it exists inside every single executable on your entire system. On the off-chance that you try to run the EXE in MS-DOS, then DOS only understands the "MZ" header and executes the DOS "stub" executable to print out the message. On Windows, it'll ignore the MZ executable. Except for reading the MZ header to find that "offset to New Executable" field to find the real Windows executable. Now, I said that it wastes 4KB. But surely a DOS executable to just print "This program requires Microsoft Windows." doesn't need 4KB to do that? It doesn't. But unless you supply some arcane options to Microsoft's linker then it'll automatically align the "New Executable" to a 4KB page boundary. An efficiency / performance thing, that Windows can just page in the real Windows executable neatly on a page boundary. If you dig through the Microsoft Linker options, there is a means to tell it not to use that alignment, but it will do so by default. Therefore, as I say, to produce a 4KB demo file, you actually CANNOT just use the linker with its default options, or it will automatically waste 4KB on this "MZ" executable, tacked onto the front, which just informs DOS users that they need Windows to run it, before you've even reached the header - much less the code and data - of the actual Windows executable. So, these 4KB demos have to mangle a fake "MZ" header - you won't be able to run them under DOS and get a friendly "This program requires Microsoft WIndows" message out of them, as they're not wasting bytes on that - that actually has a "offset to New Executable" that points to the Windows executable that's now where that "MZ" executable would have been and squeezes it all in that first 4KB page. You do have to have a valid "MZ" header, but demo coders have worked out the exact byte where you can give up on the "MZ" header and start your actual Windows executable, but Windows will read it as a valid executable (because Windows does need a valid "MZ" header up to a certain point, as it needs to read it to locate where the Windows executable lives). This is the madness of trying to cram code into 4KB. By default, the linker won't even allow you to do it, as it'll throw away the first 4KB on pointless DOS compatibility, if you don't tell it otherwise. And, yeah, just consider all the EXE and DLL files on your Windows system. All of them throwing away 4KB at the start to print "This program requires Microsoft Windows". That message does not come from DOS, it actually comes from the executable. Granted, what's 4KB when we have terabytes of hard drive space? But, still, a thousand DLL files sitting in "system32" or wherever is eating 4MB of disk space with the exact same linker-supplied redundancy of a DOS program that does nothing more than tell DOS users that it's not a DOS program. All of them. In the whole system. The underlying reason why this madness happened is that DOS (and CP/M, from which DOS is a shameless clone thereof) had an original executable format called ".COM" - short for "command" - and this format was, in fact, not a format at all. It was just up to 64KB of raw machine bytes. No header information at all. It's just raw machine code bytes that are copied into a 64KB memory segment and then executed from the first byte. ".COM" files are header-less. No "magic number" to identify them. Those first bytes can literally be anything (well, they'll be machine code instructions, one hopes, as DOS will make the CPU jump to the first byte but there's actually no enforcement of that, as there can't be, because ".COM" files have no header and no "magic number", so they cannot be (easily) distinguished from, well, any file of random bytes, save for the ".COM" file extension - and, yeah, if you've ever wondered why Windows is insistent on file extensions, where it's more "advisory" on UNIX and it rather goes by "magic numbers" and file heuristics, that's the historical underlying reason. The ONLY thing denoting a ".COM" file is that file extension... and that precedent has persisted in the Windows ecosystem from then on, that file extensions are important. While UNIX has always had less of a dependence on that and prefers looking for the bytes "ELF" at the start of a file to tell you what it is, as that platform never had the silliness of a header-less executable format, even if CP/M - and DOS cloning it - were all clones of UNIX, in the end, their implementations took shortcuts). You see, when you hear the words "backwards compatibility", they sound good because it means that old software keeps running on new systems. But it has to be understood what you're sacrificing for that. Decades old mistakes and design flaws have to be preserved forever more. You can only add - you can never take away, nor revise old stuff. Every Windows executable - save something from the demo scene that drops it to grab every last byte - throws away 4KB of disk space, for a DOS executable "stub", that prints out that the executable isn't a DOS executable. Redundantly repeated in every single executable file in the whole system. All of them. Every last one. Meanwhile, in the UNIX / open source world, then "lateral compatibility" is possible, as you have the source code, so just recompile it to a new platform or CPU. The binary doesn't have to be at all compatible with any previous version. Your formats don't have to be binary "backwards compatible" for the rest of eternity (though, hey, they sometimes actually are, to be fair, but it's not mandated to make things work, it's a design choice) because, when you have the source, you can create binaries for any platform or CPU via your compiler. I'll give it to Microsoft, though, their operating systems truly bend over backwards to supply "backward compatibility" - including outright hacks, where the OS detects popular old programs and behaves differently just to make those work. It's very impressive hard work, on an industrial scale, maintaining that "backwards compatibility" back to DOS 1.0 (although, one wonders who is actually using that anymore?). I just feel it would have been better if they'd just designed a better system that didn't require any of that in the first place, you know? (Edit: Sorry, I got a bit rant-y there, didn't I? But, still, maybe some interesting historical stuff in there for folks to learn.)
I actually find this sort of examination extremely informative and educational. I wish there were more videos that just explained how a bunch of code worked.
When I was writing that e-mail to The Cherno, I was really curious how he would examine and explain it. I thought that it would be a lot of fun to watch. And really, he exceeded all my expectations and did an amazing job explaining it better than I could!
bruh this dude just made a whole particle system fully functional that is under 4kb in size meanwhile my hello world project casually takes up 1 gig on my hard drive ;-;
As I am porting a research paper coded in matlab to C++, this video format(your comments on a good demo IMHO) is really inspiring to get me in the flow programming mathematical equations. Cheers!
Cool demo, although stupidly what struck me was The Cherno's code colour scheme,especially the very bright highlighted word colours, would love to know how that Bright text was done
This is cool! I actually created a particle simulator as well! However, my project simulates how electrons behave and move around the nucleus of the atom. It also shows the valence shells. I used C++ and SDL. Question though: The executable is 102KB. Is 102KB bad? What would be some techniques to reduce the size?
Unless you were developing for a 4K/64K demoscene, 102 KB is very good. But you must take into account the SDL library. It is not a part of any OS, so you have to bundle it into your application or add an external dependency. Anyway, your app is probably tiny in comparison to any Electron or Qt app because the runtimes they depend on are huge.
I remember myself and a large group from all over world using demo forums to try and learn and help others using exactly these techniques! Shaders were awesome but I think people started over using them and over complicating/bloating there projects when legacy opengl could happily do this stuff... Even better try and do 3d gfx on the cpu! 😄
I'd love to hear your thoughts, or even examples, on why Particle effects in a game are so demanding and costly. This generation has seen that explosion in particle effects returning to titles like Returnal and Ratchet and Clank and such. From a technical perspective. Id love to hear breakdowns on things like that. Just the WHY of some things. Like physics. These processors claim they can do what trillions of floating point operations per second yet when anything involving heavy math like RT or physics comes into play, alot of these machines start crying. Anyway. Great stuff as always.
Don't worry 99% of this is just windows / opengl calls as well as the shader code (which is probably the most "normal" part about it). Also the code is very old school, c style, minimalistic. I wouldn't read this to understand it or learn if you aren't too knowledgable with these things but instead just enjoy what can be made with such barebones code =D
I am not an expert but as far as I know, that is GLSL code (shader code) that is compiled by passing it through an OpenGL function at runtime called "glCompileShader" (of course more steps are necessary for it to actually work). The resultant binary data would then be run on the GPU. I think most programs would get the code as a string from a separate file but it works that way too.
Am your biggest fan!!!!!!!!!!!!! You are pretty amazing am a pro now am done with your C++ series. Am starting your game engine series. My plan is try to learned C++, Java, Linux, and HTMLs. My brother in law mention C++ is the first langue to learned its is simple. Hes right. Am pro!!!!!!!!!!!!!!!!!!!!!!!!!!!! Thank you for all you do me. I wish you good luck in luck in life and programing.
Yea, that's how old school games did it before everyone had 3D graphics cards. You basically draw what you want pixel by pixel onto a backbuffer and then blit it onto the screen. Windows API has some functions to do this (BlitBit and friends) and the SDL library has something similar as well. If you want something higher level, you can take a look at Raylib. I'm pretty sure that just uses OpenGL under the hood but it doesn't require you to write OpenGL code.
@@user-sl6gn1ss8p What's a bad index? Bad index relating to an array? Yeah, I was stuck due to a problem caused by the classic Array Index Fallacy(should make a Wikipedia article) where you think the last element is array[array_size] and the first element is arrar[1].
@@shambhav9534 yeah, I meant something like that. I once managed to pass a negative index to some opengl function (and somehow it didn't simply blow up, things just got weird)
@@user-sl6gn1ss8p The major problem with OpenGL is that things don't blow up, instead it does weird things. I once passed wrong datatype values and it semi worked. I was surprised very very very much. I have no idea how it could work.
nice not linking crt. i see my old friend _fltused i see him use memcpy but not implement it himself anywhere. at least in debug memcpy shouldnt be inlined to the intrinsic.
I link to a msvcrt.dll that is built in any Windows version starting at least from Win XP. Microsoft keeps it for drivers and doesn't recommend to use it in user apps. The linker I'm using, Crinkler, already links it for me automatically. But it seems that _fltused is still necessary.
@@gideonunger7284, I also use sprintf. I could've done without it and just hardcode everything in the shader source, but initially, I wanted to make it more extensible in case I would want to create multiple different particle effects.
@@spacefishaviation276 Yeah, but its nice to try this stuff on your own. Its a good learning experience. Its kinda like writing your own lexical analyzer instead of using flex or something, you can learn a lot about regular expressions and finite state automata that way.
Thanks for watching, hope you guys enjoy this series as much as I do! ❤️ Don't forget that the first 1000 people to use the link will get a free trial of Skillshare Premium Membership: skl.sh/thecherno05211
Yeah, he has to be doing some linker logic - which includes compression, no doubt - to get it down below 4KB on Windows.
Because, in fact, Windows automatically wastes 4KB for DOS compatibility on every single ".EXE" file.
If you open an ".EXE" in a hex editor, then the first two bytes will be "MZ". These are the initials of Mark Zbikowski, the coder at Microsoft who created the DOS Executable format - he just used his own initials as the file's "magic number".
Then you have the DOS executable header and, within that, there's a "pointer to New Executable". This actually points to the Windows executable (the format of which has changed over time, as the first Windows format was "NE" - new executable, hence why the field is "pointer to New Executable" - but that's from the old 16-bit days, and there's a "PE" - Portable Executable - used from the WIN32 API, that is Windows 95, onwards and there is a 64-bit revision of PE, which is much the same but, like, expands certain fields to have 64-bit width).
So, tacked onto the front of every executable (and we're not just talking ".EXE" files, because pull up ".DLL" files or ".DRV" files in your hex editor of choice to see the "MZ" bytes that confirm that these essentially use the same underlying format too), is a functioning DOS executable.
What does this DOS executable do? It prints "This program requires Microsoft Windows" to the console and then exits.
Yeah, that message does not actually exist in MS-DOS itself, it exists inside every single executable on your entire system. On the off-chance that you try to run the EXE in MS-DOS, then DOS only understands the "MZ" header and executes the DOS "stub" executable to print out the message.
On Windows, it'll ignore the MZ executable. Except for reading the MZ header to find that "offset to New Executable" field to find the real Windows executable.
Now, I said that it wastes 4KB. But surely a DOS executable to just print "This program requires Microsoft Windows." doesn't need 4KB to do that?
It doesn't. But unless you supply some arcane options to Microsoft's linker then it'll automatically align the "New Executable" to a 4KB page boundary. An efficiency / performance thing, that Windows can just page in the real Windows executable neatly on a page boundary. If you dig through the Microsoft Linker options, there is a means to tell it not to use that alignment, but it will do so by default.
Therefore, as I say, to produce a 4KB demo file, you actually CANNOT just use the linker with its default options, or it will automatically waste 4KB on this "MZ" executable, tacked onto the front, which just informs DOS users that they need Windows to run it, before you've even reached the header - much less the code and data - of the actual Windows executable.
So, these 4KB demos have to mangle a fake "MZ" header - you won't be able to run them under DOS and get a friendly "This program requires Microsoft WIndows" message out of them, as they're not wasting bytes on that - that actually has a "offset to New Executable" that points to the Windows executable that's now where that "MZ" executable would have been and squeezes it all in that first 4KB page. You do have to have a valid "MZ" header, but demo coders have worked out the exact byte where you can give up on the "MZ" header and start your actual Windows executable, but Windows will read it as a valid executable (because Windows does need a valid "MZ" header up to a certain point, as it needs to read it to locate where the Windows executable lives).
This is the madness of trying to cram code into 4KB. By default, the linker won't even allow you to do it, as it'll throw away the first 4KB on pointless DOS compatibility, if you don't tell it otherwise.
And, yeah, just consider all the EXE and DLL files on your Windows system. All of them throwing away 4KB at the start to print "This program requires Microsoft Windows". That message does not come from DOS, it actually comes from the executable.
Granted, what's 4KB when we have terabytes of hard drive space? But, still, a thousand DLL files sitting in "system32" or wherever is eating 4MB of disk space with the exact same linker-supplied redundancy of a DOS program that does nothing more than tell DOS users that it's not a DOS program. All of them. In the whole system.
The underlying reason why this madness happened is that DOS (and CP/M, from which DOS is a shameless clone thereof) had an original executable format called ".COM" - short for "command" - and this format was, in fact, not a format at all. It was just up to 64KB of raw machine bytes. No header information at all. It's just raw machine code bytes that are copied into a 64KB memory segment and then executed from the first byte.
".COM" files are header-less. No "magic number" to identify them. Those first bytes can literally be anything (well, they'll be machine code instructions, one hopes, as DOS will make the CPU jump to the first byte but there's actually no enforcement of that, as there can't be, because ".COM" files have no header and no "magic number", so they cannot be (easily) distinguished from, well, any file of random bytes, save for the ".COM" file extension - and, yeah, if you've ever wondered why Windows is insistent on file extensions, where it's more "advisory" on UNIX and it rather goes by "magic numbers" and file heuristics, that's the historical underlying reason. The ONLY thing denoting a ".COM" file is that file extension... and that precedent has persisted in the Windows ecosystem from then on, that file extensions are important. While UNIX has always had less of a dependence on that and prefers looking for the bytes "ELF" at the start of a file to tell you what it is, as that platform never had the silliness of a header-less executable format, even if CP/M - and DOS cloning it - were all clones of UNIX, in the end, their implementations took shortcuts).
You see, when you hear the words "backwards compatibility", they sound good because it means that old software keeps running on new systems. But it has to be understood what you're sacrificing for that. Decades old mistakes and design flaws have to be preserved forever more. You can only add - you can never take away, nor revise old stuff. Every Windows executable - save something from the demo scene that drops it to grab every last byte - throws away 4KB of disk space, for a DOS executable "stub", that prints out that the executable isn't a DOS executable. Redundantly repeated in every single executable file in the whole system. All of them. Every last one.
Meanwhile, in the UNIX / open source world, then "lateral compatibility" is possible, as you have the source code, so just recompile it to a new platform or CPU. The binary doesn't have to be at all compatible with any previous version. Your formats don't have to be binary "backwards compatible" for the rest of eternity (though, hey, they sometimes actually are, to be fair, but it's not mandated to make things work, it's a design choice) because, when you have the source, you can create binaries for any platform or CPU via your compiler.
I'll give it to Microsoft, though, their operating systems truly bend over backwards to supply "backward compatibility" - including outright hacks, where the OS detects popular old programs and behaves differently just to make those work. It's very impressive hard work, on an industrial scale, maintaining that "backwards compatibility" back to DOS 1.0 (although, one wonders who is actually using that anymore?). I just feel it would have been better if they'd just designed a better system that didn't require any of that in the first place, you know?
(Edit: Sorry, I got a bit rant-y there, didn't I? But, still, maybe some interesting historical stuff in there for folks to learn.)
Привет, ты из России родом? Просто ты так хорошо разговариваешь на русском
Very nice particles
DANIS-PARTICLE ENGINE
Hi Dani! I think you will also make a game engine 😅
@@ajiteshirij9brollno-032 😂😂😂
Dani is found cheating on unity particle system.
Kinda cringe bc its not the great Unity's particle system
I actually find this sort of examination extremely informative and educational. I wish there were more videos that just explained how a bunch of code worked.
When I was writing that e-mail to The Cherno, I was really curious how he would examine and explain it. I thought that it would be a lot of fun to watch. And really, he exceeded all my expectations and did an amazing job explaining it better than I could!
bruh this dude just made a whole particle system fully functional that is under 4kb in size meanwhile my hello world project casually takes up 1 gig on my hard drive ;-;
demo scenes use compression algorithms to make the file sizes smaller
When iostream takes up 42 KB 😞
Do you develop your hello worlds in Unreal Engine or something?
Probably a JS project. JavaScript projects tend to be stupidly large (looking at you, node_modules).
Смотрю такой, ничего не подозревая, а потом как услышу русскую речь. Аж сердце закололо.
Лол ❤️
А у меня-то как закололо, когда я увидел свой проект в ленте!) Я намеренно писал именно с той почты, в которой у меня имя кириллицей написано)
Аі ұіш аі күд спӣк рашн 😔
I really like this series. Its very interesting to see your opinion on some code. Keep going!!
When you disabled blending, it was like you desecrated his whole project with two lines of code. Baaam
As I am porting a research paper coded in matlab to C++, this video format(your comments on a good demo IMHO) is really inspiring to get me in the flow programming mathematical equations. Cheers!
that was fun. It looks like you can change the music pattern to change the melody of the music or change the length.
00:32 Thanks cherno....really need that
YES! Another Code review!
@The Cherno неплохо ты произношение натаскал. я, не глядя в комментарии, даже не услышал акцент.
crickler actually using a hash to access the DLL functions - the strings aren't compressed - they aren't included! (c: Thank for the video.
When you read code like I read a book...Ninja level Cherno!
When I first read the title I was thinking you took a look at Returnal🤣
Returnal is on a different level of particle / voxels - look at the way things explode in tiny cubes 🤩
@@elysiumcore I know. Iam playing it right now..
3:39. Yep, that's what we sometimes called 'missing a cut'. And it's during a sponsor spot as well. What a flop
Im glad you showed the demoscene culture to your channel!
Cool demo, although stupidly what struck me was The Cherno's code colour scheme,especially the very bright highlighted word colours, would love to know how that Bright text was done
This is cool! I actually created a particle simulator as well! However, my project simulates how electrons behave and move around the nucleus of the atom. It also shows the valence shells. I used C++ and SDL.
Question though: The executable is 102KB. Is 102KB bad? What would be some techniques to reduce the size?
Unless you were developing for a 4K/64K demoscene, 102 KB is very good. But you must take into account the SDL library. It is not a part of any OS, so you have to bundle it into your application or add an external dependency. Anyway, your app is probably tiny in comparison to any Electron or Qt app because the runtimes they depend on are huge.
Thanks Yan! Huge Fan! Love C++. Great Work!
Так, значит русский язык знаешь...
У него уже было видео, где он на русском его начал
Я даже сам афигел
I remember myself and a large group from all over world using demo forums to try and learn and help others using exactly these techniques! Shaders were awesome but I think people started over using them and over complicating/bloating there projects when legacy opengl could happily do this stuff... Even better try and do 3d gfx on the cpu! 😄
I missed this series!
I'd love to hear your thoughts, or even examples, on why Particle effects in a game are so demanding and costly. This generation has seen that explosion in particle effects returning to titles like Returnal and Ratchet and Clank and such.
From a technical perspective. Id love to hear breakdowns on things like that. Just the WHY of some things. Like physics. These processors claim they can do what trillions of floating point operations per second yet when anything involving heavy math like RT or physics comes into play, alot of these machines start crying.
Anyway. Great stuff as always.
That looks so trippy 24:40
oof the confetti effect on full display in this video lol. But still enjoyed the great content!
Interesting video! Do you know guys what color scheme is The Cherno using for syntax highlighting?
flawless ad read 👌
So yeah, 4k demo(scene?)
Is a softwere is a game engine?
Hey, are you having trouble debugging this code?
Hey Yan, do you take any personal c++ classes. I am really amazed by your skills. Really love c++ and graphics programming🙂
I feel really dumb watching this, I have no clue what’s going on wtf. I thought I knew C++
Don't worry 99% of this is just windows / opengl calls as well as the shader code (which is probably the most "normal" part about it). Also the code is very old school, c style, minimalistic. I wouldn't read this to understand it or learn if you aren't too knowledgable with these things but instead just enjoy what can be made with such barebones code =D
@@the0neskater sheesh you're big brain👍👍
👏👏 CODE 👏👏 REVIEW 👏👏
:D
how is half his code stored in a string (I'm new to c++ so let me know if I'm missing something
I am not an expert but as far as I know, that is GLSL code (shader code) that is compiled by passing it through an OpenGL function at runtime called "glCompileShader" (of course more steps are necessary for it to actually work). The resultant binary data would then be run on the GPU. I think most programs would get the code as a string from a separate file but it works that way too.
you are a legend, many thanks
Am your biggest fan!!!!!!!!!!!!! You are pretty amazing am a pro now am done with your C++ series. Am starting your game engine series. My plan is try to learned C++, Java, Linux, and HTMLs. My brother in law mention C++ is the first langue to learned its is simple. Hes right. Am pro!!!!!!!!!!!!!!!!!!!!!!!!!!!! Thank you for all you do me. I wish you good luck in luck in life and programing.
Is there a way to write C++ code just to draw any shapes and colors not using openGL and normal C++ code.
Yea, that's how old school games did it before everyone had 3D graphics cards. You basically draw what you want pixel by pixel onto a backbuffer and then blit it onto the screen. Windows API has some functions to do this (BlitBit and friends) and the SDL library has something similar as well. If you want something higher level, you can take a look at Raylib. I'm pretty sure that just uses OpenGL under the hood but it doesn't require you to write OpenGL code.
Great series! Thanks
Hey Cherno. Try to make video on Русский) Russian audience will approve
Do you only review C++ projects?
Or is it OK if I send you a C# project.
send and see:D
How are you, Cherno? :) Good stuff
I didn't knew cherno spoke russian...
that was very cool
I'm getting a bug in my very very small OpenGL game's *start,* yes the start. I can't even render anything. What may be the major reasons be?
maybe passing something a bad index?
@@user-sl6gn1ss8p What's a bad index? Bad index relating to an array? Yeah, I was stuck due to a problem caused by the classic Array Index Fallacy(should make a Wikipedia article) where you think the last element is array[array_size] and the first element is arrar[1].
@@shambhav9534 yeah, I meant something like that. I once managed to pass a negative index to some opengl function (and somehow it didn't simply blow up, things just got weird)
@@user-sl6gn1ss8p Those .problems usually happen in the Vertex Attribute sections, time to check it hundred times.
@@user-sl6gn1ss8p The major problem with OpenGL is that things don't blow up, instead it does weird things. I once passed wrong datatype values and it semi worked. I was surprised very very very much. I have no idea how it could work.
12:02 it's a little bit what now
Doge
#TOTHEMOON
Ilikedit!
You should make a ImGui particles tutorial that would be sick
ImGui has nothing to do with particles. It's a GUI library.
@@catinwall4256 I’m very aware. I’m just asking him to make a tutorial on how to add particles in a ImGui window.
@@simplifiedcontenttoday But why? That's not really a thing you can do.
@@catinwall4256 You can do it I’ve seen someone on RUclips do it
He's done it before
how many languages do u speak?
pozdrowienia z kraju, gdzie też potrafimy wymawiać Rrrrr... xD
Черно) Откуда ты?:) Откуда твои предки?:)
mean programmer: i'm gonna move this vertex shader to the cpu
pc: oh god please no 😩
cool !! thanks very much Yan
3:44 LOL
🎉
I LOVE YOUR VIDS MAN!! KEEP IT UP! PLZ HEART?
nice not linking crt. i see my old friend _fltused
i see him use memcpy but not implement it himself anywhere. at least in debug memcpy shouldnt be inlined to the intrinsic.
ok he links some msvcrt.lib from bin
I link to a msvcrt.dll that is built in any Windows version starting at least from Win XP.
Microsoft keeps it for drivers and doesn't recommend to use it in user apps.
The linker I'm using, Crinkler, already links it for me automatically.
But it seems that _fltused is still necessary.
@@Alexander-5V why link crt at all when all you use from it is memcpy?
@@gideonunger7284, I also use sprintf. I could've done without it and just hardcode everything in the shader source, but initially, I wanted to make it more extensible in case I would want to create multiple different particle effects.
Pretty cool I guess, I prefer just using Godot built in particles or Unity
LOL
Yep people spent all their time building something cool but Godot and unity is always gon be better
@@spacefishaviation276 Yeah, but its nice to try this stuff on your own. Its a good learning experience. Its kinda like writing your own lexical analyzer instead of using flex or something, you can learn a lot about regular expressions and finite state automata that way.
@@lucass8119 yeah, I posted that before I created my own engine XD I've started work on an engine and it would be very cool to have a particle system
Crazy Russian hackers liked this comment
But your name is NOT "The Cherno".
I made a bet whether you know Russian or not🤔
хочу квас
Хочю оливье
lol
Nice russian pronunciation. Родственники русские?
Cherno is short from Chernikov, his surname. So I guess so?
Do a video in Russian!!
Please upload more Game Engine videos, you are very slow
Chill bro lol
FIRST!
You're third, even when you actually are first you will still be third. Here's your sign - "ALWAYS 3RD"
You were second comment, third viewer