As several people have pointed out, this video is a wrong representation of how Terraria actually works. It turned out to be more of a discussion of my own ideas and solutions. I am sorry for spreading misinformation. The inaccuracies were neatly pointed out by user Mirsario, who I will quote directly to lay out all the mistakes I made in the video and their rectifications. Thanks Mirsario (and others) for taking your time to point all of this out. " ==Relation to Terraria== 1:00 - It doesn't keep track of anything. They just sit in memory, this is not a physics simulation. There are also really not a lot of tiles, the "Large" world size is just 8400x2400. 2:16 - Your Unity3D object-oriented rendering has nothing to do with Terraria, XNA, and its SpriteBatch rendering. It wouldn't have been possible for the game to render so slow in the worst of the worst cases. Additionally, the game only renders tiles 12 times a second, rendering to a texture. 2:45 - No, the game has no object-oriented tile logic. Nothing in it is object-oriented, actually. And that's a good thing for tiles. Your idea is really, really bad. 3:54 - Frustum culling is a 3D technique that has nothing to do with 2D and non-object-oriented designs. Like the ones Terraria spams tons of. Cutting off off-screen stuff in 2D is nothing but a check for rectangle bounds, which is hundred times faster and simpler. 4:48 - Chunks? Yeah, Terraria has none of that. At all. It never did. It just uses a giant Tile[,] array, which is idiotic, but works for vanilla version of it. 5:13 - "If a tree falls in Terraria and it isn't happening on screen... Does it still make a sound?" Yes. It tries to. 5:37 - Yes, all tiles are active at all times. Trees grow when they grow. Only multiplayer clients don't get all world data immediately, and that's all. The way these trees grow is not through some magic object-oriented Tile.Update() calls (no methods like that exist), but through the world's update method, which, again, idiotically, picks like 1000 (depends on world size) random positions every update to do various logic like that, like spreading grass onto dirt if the randomly picked tile is grass. 5:56 - This has no correlation with the game. You could also at least say to store your made-up timers in your made-up chunks. " - Mirsario (altered slightly) Additional points made by Fevix Darkwatch: " 1) Terraria is in no way procedurally generated as you play. The moment you first spawn in, before you've even taken a step, you can exit, load the world in an external editor, and view the entirety of the world, from corner to corner, which brings me to.... 2) There are NOT "Theoretically infinite" tiles in Terraria. Each map size (Small, Medium, and Large) has a hardcoded height and width. You can very easily reach all four edges of the world. The sizes can be seen here, along with total blocks available: terraria.fandom.com/wiki/World_Size 3) Tiles don't activate/deactivate based on distance to the player. Teleporters can work across the entire world's width even without another player standing near the other end. Water falls, even offscreen. Trees grow on their own, even hundreds of blocks away. This can all be seen by using a mod to constantly reveal the entire map ingame while it's running, allowing you to watch from a distance as trees, plants, grass, and water all moves without any players nearby. Terraria uses its own custom engine which can only do one thing, but it does it very, very well: Run Terraria. Blocks don't keep track of their status constantly, either. When a player starts mining a block, THAT BLOCK starts keeping track of its status to determine how much damage it's taken (Better picks do more damage) and when it reaches a threshold it breaks and drops an item. When a block isn't being interacted with, it's pretty much inert, doing nothing and contributing no load aside from render. 4) In addition, you can save a LOT of rendering time by using a buffer of sorts. Render the visible area once, apply a lighting filter layer to darken areas that aren't lit (or color areas that are lit with a colored light), and saving that render somewhere, optimally in RAM provided it's small enough. As the player moves, chop off bits that fall off one side, and render only the bits that come in from the side. Re-render a small area around tiles that get updates (Trees growing, grass spreading, block mined) and boom, instead of rendering thousands of tiles per frame, you only have to render a couple dozen unless some massive changes are happening, EG someone just released a giant flood of water into the caves. " - Fevix Darkwatch (altered slightly) Some more broad points made by Mirsario: " ==How useful this is to game developers== First of all, he brings up an issue that's not real anywhere but in his example, which is him using OOP Unity rendering without any real batching. The way XNA's SpriteBatch (which Terraria uses) works (in immediate mode, which avoids sorting) is by creating a buffer (you can think of it as a mesh/3d model created for just one frame), and putting vertex data into it. Then it's all uploaded to the GPU with one call and drawn with another. It's all really quick. The way Unity3D rendering works is, like in any 3D engine, by storing data about what needs to be rendered, then sorting that data, then doing a draw call per mesh in just an optimized order (to avoid frequent calls that switch shader programs, but not to avoid draw calls). These sorting optimizations only hurt us with such hierarchies, as they're a very good example of optimizations with trade-offs. Unity3D does have batching, but only for objects marked as static, and he clearly didn't use that. So, rendering optimization has never been an issue to begin with, with something so simple as Terraria (or any game like that with a finite world, that is, Starbound too). Then he brings up frustum culling. I've already mentioned how unrelated this is. Let's just say that it's another overhead for his 'issue example'. Then, he talks about object-oriented designs on tiles. You don't do that. This is not a physics simulation, and if you want to make one - please use GPUs, not CPU. Object-Oriented-Programming is amazing for humans, but not for CPU performance. If you're doing C#, then please only use structure and not class Tiles (which Terraria did use, very stupidly, as it's just more memory usage and more stress for garbage collection). C# 7's ref variables have made structs like that a blessing to use. Now, if I ignore the design shenanigans, the time comparison for when tiles get loaded sounds like a sane way to have freezable logic, but only if you don't plan on updating a tile 1000 times because it was unloaded for 1000 ticks, AND ONLY if timers are placed on chunks, not on tiles. That'd be an extreme optimization with zero cons, and missing it shows his mindset. Or the April 2, 2017 him. Programmers evolve, and I can't say that I wasn't a total pushover 5 years ago. This really does only work with chunks, because for many operations you will need to know information about adjacent tiles. For simple grass spread, you'll need a system that can load neighboring chunks at chunk load distance's corners, without updating them unless they move into the real load distance. Sigh. I have recently worked on making a 2D game (on my own engine) with an infinite world (this guy's weird designs suggest that they're about infinite worlds), and I have to say: The only optimization needed was about generating chunks (No matter how fast your noise is, it's never fast enough), their saving & loading code, and their textures (but that only requires writing something that's like XNA's SpriteBatch, if you're just on that engine - this is not a problem). This vid is really a bunch of made-up issues and incompatible made-up solutions. If this is anyhow about recommendations to game developers - it'd be superior to actually describe how Terraria works, and advise against many of its points, as it works, quite frankly, idiotically* at many points**. Terraria only works well because the issues stated in this video are not issues at all. They just don't exist. * - Re-Logic members do know, and perhaps 1.4 will rewrite many points, but it's not financially viable for them to do, as some once said, which is agreeable. ** - but it runs fine for what it is. As someone else in this comment section approximately said, this game is written to be nothing more but this exact game. " - Mirsario (altered slightly)
Good to know the truth ! You've made a mistake when you forgot to mention that it was your ideas and not the actual solutions in terraria but, hey, making a mistake is ok as long as you admit (and you did) You should totally remake this vidéo!
@HuffmanTeamGaming why would he do that? Doesn't it take views away from his channel? Also this video can bring in more people that can watch his newer content, which is correct, as far as i've seen. It's pretty hard tp miss the big "redacted" in the title
@HuffmanTeamGaming Clearly a lot of work went into this video, and although it may not be accurate to what terraria actually does, it still shares some awesome ideas and solutions to various problems in games, and honestly he probably wouldn't even have to change the title if he just pushed it as how he would do it, as opposed to how it is done.
Wow, what happened? Two years after I stopped posting the youtube algorithm comes along and now this! :D Guess it's time to start working on that procedural generation video! Thank you all for the kind comments! Since 2017, this channel has since been sort of an abandoned project of mine. I can't lie.... that really makes me want to make new content.
Terraria world generation is a lot simpler than Minecraft's, etc. since it is a closed world (Not procedural!) Terrain: 2D Perlin/Simplex noise. Caves are a lot more complicated though Trees: I've made an algorithm for spacing them out and I'm not sure what Terraria does. What I do is check if a noise value is greater than the 3(+) values around it Ores: For every chunk (Like 64 size) spawn a random amount of ore patches Stuff like temples, pyramids, and the dungeon probably have much more complicated algorithms that I would not know about
God, this video is a joke. There are so many things wrong, that I've split the following into 2 parts. Please read everything if you have the stamina, otherwise, well.. hm. ==Relation to Terraria== Nothing in this has any correlation with the game. Things aren't as good, and aren't as terrible. 1:00 - It doesn't keep track of anything. They just sit in memory, this is not a physics simulation. There are also really not a lot of tiles, the "Large" world size is just 8400x2400. 2:16 - Your Unity3D object-oriented rendering has nothing to do with Terraria, XNA, and its SpriteBatch rendering. It wouldn't have been possible for the game to render so slow in the worst of the worst cases. Additionally, the game only renders tiles 12 times a second, rendering to a texture. 2:45 - No, the game has no object-oriented tile logic. Nothing in it is object-oriented, actually. And that's a good thing for tiles. Your idea is really, really bad. 3:54 - Frustum culling is a 3D technique that has nothing to do with 2D and non-object-oriented designs. Like the ones Terraria spams tons of. Cutting off off-screen stuff in 2D is nothing but a check for rectangle bounds, which is hundred times faster and simpler. 4:48 - Chunks? Yeah, Terraria has none of that. At all. It never did. It just uses a giant Tile[,] array, which is idiotic, but works for vanilla version of it. 5:13 - "If a tree falls in Terraria and it isn't happening on screen... Does it still make a sound?" Yes. It tries to. 5:37 - Yes, all tiles are active at all times. Trees grow when they grow. Only multiplayer clients don't get all world data immediately, and that's all. The way these trees grow is not through some magic object-oriented Tile.Update() calls (no methods like that exist), but through the world's update method, which, again, idiotically, picks like 1000 (depends on world size) random positions every update to do various logic like that, like spreading grass onto dirt if the randomly picked tile is grass. 5:56 - This has no correlation with the game. You could also at least say to store your made-up timers in your made-up chunks. If you're a C# programmer, DigiDigger (that's only an assumption based on you using Unity), then why didn't you just decompile the game and have at least a single look at it? ILSpy and dnSpy can easily let you do that. ==How useful this is to game developers== Even if we ignore this being about some game, his designs aren't optimization. First of all, he brings up an issue that's not real anywhere but in his example, which is him using OOP Unity rendering without any real batching. The way XNA's SpriteBatch (which Terraria uses) works (in immediate mode, which avoids sorting) is by creating a buffer (you can think of it as a mesh/3d model created for just one frame), and putting vertex data into it. Then it's all uploaded to the GPU with one call and drawn with another. It's all really quick. The way Unity3D rendering works is, like in any 3D engine, by storing data about what needs to be rendered, then sorting that data, then doing a draw call per mesh in just an optimized order (to avoid frequent calls that switch shader programs, but not to avoid draw calls). These sorting optimizations only hurt us with such hierarchies, as they're a very good example of optimizations with trade-offs. Unity3D does have batching, but only for objects marked as static, and he clearly didn't use that. So, rendering optimization has never been an issue to begin with, with something so simple as Terraria (or any game like that with a finite world, that is, Starbound too). Then he brings up frustum culling. I've already mentioned how unrelated this is. Let's just say that it's another overhead for his 'issue example'. Then, he talks about object-oriented designs on tiles. You don't do that. This is not a physics simulation, and if you want to make one - please use GPUs, not CPU. Object-Oriented-Programming is amazing for humans, but not for CPU performance. If you're doing C#, then please only use structure and not class Tiles (which Terraria did use, very stupidly, as it's just more memory usage and more stress for garbage collection). C# 7's ref variables have made structs like that a blessing to use. Now, if I ignore the design shenanigans, the time comparison for when tiles get loaded sounds like a sane way to have freezable logic, but only if you don't plan on updating a tile 1000 times because it was unloaded for 1000 ticks, AND ONLY if timers are placed on chunks, not on tiles. That'd be an extreme optimization with zero cons, and missing it shows his mindset. Or the April 2, 2017 him. Programmers evolve, and I can't say that I wasn't a total pushover 5 years ago. This really does only work with chunks, because for many operations you will need to know information about adjacent tiles. For simple grass spread, you'll need a system that can load neighboring chunks at chunk load distance's corners, without updating them unless they move into the real load distance. Sigh. I have recently worked on making a 2D game (on my own engine) with an infinite world (this guy's weird designs suggest that they're about infinite worlds), and I have to say: The only optimization needed was about generating chunks (No matter how fast your noise is, it's never fast enough), their saving & loading code, and their textures (but that only requires writing something that's like XNA's SpriteBatch, if you're just on that engine - this is not a problem). This vid is really a bunch of made-up issues and incompatible made-up solutions. If this is anyhow about recommendations to game developers - it'd be superior to actually describe how Terraria works, and advise against many of its points, as it works, quite frankly, idiotically* at many points**. Terraria only works well because the issues stated in this video are not issues at all. They just don't exist. * - Re-Logic members do know, and perhaps 1.4 will rewrite many points, but it's not financially viable for them to do, as some once said, which is agreeable. ** - but it runs fine for what it is. As someone else in this comment section approximately said, this game is written to be nothing more but this exact game. I do understand some people's point that it was an interesting video to watch when you know that most of it is wrong, but not everyone does, and the fact that it's not mentioned anywhere that it's nothing but a discussion of his own ideas makes it awful content. The ones interested in this channel wouldn't be against DigiDigger's content becoming better, from either more research (or ANY RESEARCH, GOD!), or a different presentation that mentions when something (in this video's case that'd be everything) is speculation. DigiDigger, if you did read this - do reply.
Yes this is not how terraria does it but this video does teach optimisation so it's more a tutorial on optimisation so it's more mislabeled. I wouldn't call it a joke but more a tutorial
@@eliaslamsa6541 -I have replied to someone else making basically the same point as you in another comment branch. Can't really link it since I'm typing from a phone, so I'll just copy-paste it, but it's another wall of text, beware.- EDIT: Merged that other comment with my previous one.
Minecraft: "procedurally generated" Terraria: "procedurally pre-generated" (confusion solved. lol) many of us have misinterpreted "procedurally" to mean "on the fly". there's no shame in it. because what it actually means is kind of redundant. "using procedures". doesn't "generate" already imply there'll be "procedures"? lol so anyone thinking of something distinguishable would think of "on the fly" / "bit by bit".
This video oddly tries to make this harder than it actually is. Drawing tiles is one of the easiest tasks your computer can do. But if you use Unity engine to showcase that obviously it will seem as if thats something demanding, not because its hard, but because Unity's graphics pipeline is simply not built for that. When you actually code your own renderer however, rendering let alone thousands, even millions of tiles can easily be done in real time with proper instancing. And you can easily use instancing on a game like terraria. So yeah, Terraria isnt exactly a game that is difficult to render unless coded horribly. On a game like Terraria, if you are coding your own renderer, you can render all blocks of same type in a single draw call. Draw calls are the real performance hitter. You can reduce thousands of draw calls to less than a hundred.
Exactly. Even the dumbest, simplest possible implementation won't run into any performance problems for a game like this. Assuming one texture atlas, 10,000 tiles on-screen, 6 vertices per tile (2 triangles, no index buffer for simplicity), vec2's for position and texture coords, that's 10000 * 6 * (2*4 + 2*4) = 960,000 bytes, less than a megabyte of trivially computable data. Just toss that data into a single vertex buffer and upload it to the GPU every frame, problem solved.
@@kicklemon1948 cause he gets a giant ego-boost from pointing out other's mistakes. The worst thing is, it's not even like other comments, which constructively point out why the video is basically all false, he went around commenting "FinD A BeTteR ChaNnEl"
@Chickentenders A bad developer blames the tool. I've played unity games that run like ass and I've played unreal games that run like ass. It's just that there are more inexperienced developers using unity as it's easier to develop for.
that's how the video should have went tbh just "how does terraria handle so many tiles?" "it doesn't run on unity" "thank you for watching the video, see you around next time!"
@Chickentenders Unity is a great engine that since it has a freeware version a lot of shity games are done with it, a game like Escape from Tarkov is made in unity and runs amazingly well.
@Chickentenders Developers suck at optimization. I've played more laggy Unreal games than Unity games, just about any engine can create a game that runs smooth as butter, it's simply down to the skill level and amount of effort put in by the devs.
@@villager1831 This video was like wild guesswork, for a problem that didn't exist, and doesn't even hold up in the context of Terraria. 8k tiles on screen? why ever would that lag? or fry your pc? or crash? If you only store the time a tile was last updated and then use the delta later, then why the hell does liquid in Terraria keep getting updated? I don't understand why people like this video since it's just so wrong.
@@villager1831 None of what he described is specific to Terraria. In fact these techniques are bare minimum expected optimisation on every game (where applicable). He also very clearly has no understanding of Terraria itself too.
Like, for example: "The amount of tiles in a Terraria world is theoretically infinite." (not exact quote) Like, WHAT? Terraria worlds are CLEARLY finite. There's even the world size options!
Terraria modder here. I’ve been working with this game and it’s inner workings for almost a year now, and a lot of things here aren’t accurate. First of all, Terraria’s worlds are finite and are generated only once. I’m not sure how the conclusion that it was infinite was reached, but that’s one of the more obvious errors here. Terraria uses a random tile update function to handle things like the growth of grass and crops, spread of biomes, etc. This happens randomly and can affect any tile. While I’m not sure how often it’s called, it can happen to any tile regardless of where it is. Second, tiles are absolutely not updated every frame. Or, more specifically, when you leave them alone. Terraria uses a function to tell the game if a tile has been interacted with in some way, and it updates the tile appropriately. This includes things like liquids flowing, tile textures connecting, etc. If you were to modify a tile (let’s say by adding some water) without telling the game that the tile needs to be updated, it would just stay. (our water block in this example would float in mid-air and not flow) This is actually similar to what Minecraft does in some ways (although I have no idea how Minecraft does it). In Minecraft, if you were to add a sand block, for example, via a third-party editor or otherwise, it would remain in place until an adjacent block is updated. The example of updating a timer each frame as shown in this video does not apply at all to how tiles work. The total number of tile updates, due to this system, isn’t actually that large. The game would suffer if a lot of those took place at once. If you’ve ever tried to drain an entire ocean into Hell, for example, the massive number of updates the game has to deal with slows fluid processing to a halt and it takes forever for any liquids to update. An exception to this would be tile entities, such as chests, which are updated each frame and can contain additional information and functions. However, there are usually relatively few of these in the world, so their effect on performance isn’t bad. One more thing: Terraria was built around Microsoft’s (now discontinued) XNA framework, which is less of an engine and more of a useful set of resources and tools. Using it, Terraria contains it’s own graphics engine designed to handle the game’s graphics. It does not use any sort of engine like Unity.
Also he got rendering wrong. His 20fps is caused by the cpu making a draw call to the gpu for every individual tile. Probally a side effect of having every tile being a unity entity. Tile chunks should be stored in gpu memory with a single draw call per chunk
Just like how I didn't "find" that sock I was missing; it just turned out to be sitting on my table. But a box fell over so that I could see it, and I'm grateful that this happened.
'great channel'? he compared the terraria tiles on screen to 8000 unity Game Objects which is just nuts- unity is over-engineered, so it's not surprising that 8k GOs could consume way more than 8k bytes and 8k flops, put 3.5 minutes of fluff before attempting to answer the question, had a bogus question in the first place(Q: how does terraria handle 8000 tiles on your screen? A: your computer does trillions of operations per second, why wouldn't it work?), and is missing the real way to save on performance with tilesets(upscaling on the GPU after storing tiles as individual pixels in a texture), Surely you can find better technical channels on youtube... More notes: -Frustum culling involves rendering boxes to determine if the high-quality mesh should be rendered, and this isn't at all like what terraria does. There isn't even a frustum. -updating certain chunks every tick can save on performance, but for a game like terraria, it just isn't worth it. This wouldn't work on liquids like lava or water, either, which need to be simulated in real-time
@@null3377 what the hell is a micro operation For channels, I would suggest computerphile at the least. and this guy is a legend, but maybe not as entertaining: yt.com/channel/UCdmAhiG8HQDlz8uyekw4ENw sadly I don't have any recommendations that both captivating and informational on computers. I can only say that this channel does not present real information.
@@null3377 You made that term up. If a 'micro' operation is 2 inputs -> 1 output on the hardware level, then what exactly is an operation? Why are GPUs measured in teraflops? FLOPs stands for FLoating-point OPerations per second. Is a teraflop not one trillion floating point operations? No one's going to be mad if you're wrong on the internet, and I don't think you should argue the point
For those who are wondering how terraria procedural generation works, since apparently he hasn't uploaded a video for it, I can explain it to you. I created a version of terraria for my AP computer science midterm project. Here's what I did: - start with a seed. This will ensure same generation every time. When you want a random number, you input a seed, it does some calculations, and outputs a pseudorandom number based on the number you put in. So, what you can do is keep feeding the output of the random number to get a new one, and if you have the same seed it will always do the same "pattern" - Next you want to sprinkle random stone blocks around your blank world, this will start off the generation. - Then, for every tile, if there is a tile next to it, there is a random chance it will become a tile. Do this enough times and your world will now have clumps, then mountains. depending on how you check for tiles around it, you'll get different results. However, this is not how Terraria generates its terrain. - After that, you can add water to all the empty tiles that are at or below sea level - Then, add dirt to all the tiles that have air directly above it and stone directly beneath it, then each tile you set to dirt, set the other 3 directly below it to dirt, and the top one to grass. - You do the same thing but for sand underwater. - For ores, you can have a random low chance of generating one in place of a stone tile, and then a random chance for the ones next to it to become the same ore. - finally, you want to add trees. Check every grass block, and if there is a large enough rectangle of space above it, generate a tree. This method will do good, but will make a bunch of floating islands, which, if that's not what you want, you can use Perlin Noise at the start Terraria doesn't have floating islands, instead, it has a ground and a cave system next to it. Here's a simple way to generate it using Perlin Noise: - Start of halfway on the y axis and set a variable to your current y value. On the y value (let's call it y0), start at the very left and add a grass tile at that value, 3 dirt tiles below it, and stone all the way to the bottom. - Do this for every block, but change y0 by an integer between [-n, n], where n is how steep you want the hills to get. for better results you can use Gaussian (normal) distribution to pick the change in y0. - Any empty tile that is at or below sea level now becomes water - For the caves, start at a random point in the cave and make a line to another point 5 tiles away in a slightly changed direction. Make a chain of lines a random number of times and that will be a single cave path. You can make any number of chains, chains can split like a tree, whatever, until you have enough caves. - Next is to remove every tile that is 4 tiles away from any line, and this will make cave tunnels with a diameter of 8 tiles - Next, you can fill some of the caves with water or lava, by random chance or by how high up the cave is. - You make trees the same way, but since there are no floating islands, you don't need to check for tiles above it This is an oversimplified way to generate it, but terraria is much more complex and adds biomes, buildings, dungeons, and a lot more things. It's called procedural because it follows a set procedure, or order, of things to generate. Hope this helps!
Every world in terraria has floating islands specifically added to it during world generation. Small worlds have up to 4 of them, and Large worlds can have up to 8. terraria.gamepedia.com/Floating_Island. I'll admit it doesn't have the KIND of floating islands you mentioned (Noise-generated), but it does most definitely have many above-ground clusters of blocks. I'm not going to pretend to know how Terraria's caves are generated, but the cave generation you described would make many samey caves, not to mention it doesn't account for the unique generation in certain biomes like the Underground Desert or the Underworld.
Looks like UA-cam decided to recommend a video from several years ago by a channel that has been inactive since said video to a whole bunch of people again.
This video should be full of "I think" asterisks, because many of your points are demonstrably false. 1) Terraria is in no way procedurally generated as you play. The moment you first spawn in, before you've even taken a step, you can exit, load the world in an external editor, and view the entirety of the world, from corner to corner, which brings me to.... 2) There are NOT "Theoretically infinite" tiles in Terraria. Each map size (Small, Medium, and Large) has a hardcoded height and width. You can very easily reach all four edges of the world. The sizes can be seen here, along with total blocks available: terraria.fandom.com/wiki/World_Size 3) Tiles don't activate/deactivate based on distance to the player. Teleporters can work across the entire world's width even without another player standing near the other end. Water falls, even offscreen. Trees grow on their own, even hundreds of blocks away. This can all be seen by using a mod to constantly reveal the entire map ingame while it's running, allowing you to watch from a distance as trees, plants, grass, and water all moves without any players nearby. Terraria uses its own custom engine which can only do one thing, but it does it very, very well: Run Terraria. Blocks don't keep track of their status constantly, either. When a player starts mining a block, THAT BLOCK starts keeping track of its status to determine how much damage it's taken (Better picks do more damage) and when it reaches a threshold it breaks and drops an item. When a block isn't being interacted with, it's pretty much inert, doing nothing and contributing no load aside from render. 4) In addition, you can save a LOT of rendering time by using a buffer of sorts. Render the visible area once, apply a lighting filter layer to darken areas that aren't lit (or color areas that are lit with a colored light), and saving that render somewhere, optimally in RAM provided it's small enough. As the player moves, chop off bits that fall off one side, and render only the bits that come in from the side. Re-render a small area around tiles that get updates (Trees growing, grass spreading, block mined) and boom, instead of rendering thousands of tiles per frame, you only have to render a couple dozen unless some massive changes are happening, EG someone just released a giant flood of water into the caves.
I was hoping a real programmer would show up. I wanted to also add that in all likelihood, Terraria does not function like a true tile engine would where it draws each individual tile as separate objects, or tiles. Rather, the smart way to do it is to indeed have each tile exist as its own object derived from a C++ class, but it for the most part only exists as code. Each tile object knows its x/y position and what pixels are associated with it, but the way it draws itself is simply "bit blitting" itself to the buffer. Take a look at that first landscape shot of Terraria in the video - thousands of tiles, but only a handful of bitmaps that are unique. That makes it terribly easy to store in memory and very easy to blit the same square of pixels to the buffer over and over again. It's like if you wanted to stamp your name onto a letter your wrote and were going to write 8000 letters, you don't need a unique stamp for each letter. You can use the same damn stamp and just use it over and over again. Same with tiles. Each tile just has "bluesky" as a string in a variable and the engine knows that refers to a specific square of pixels in the "master tile image" that probably houses all unique tile in it. So, it's just bit blitting that same square over and over again for each tile even though there are thousands of the same tile. Even if Terraria did keep tiles "active" after they went off screen, that would still be pretty easy to do since they just have to exist as code. It's not like there is any drawing going on outside the screen, which is the most intensive process games do.
I would like to comment on a few(all) of your points, i'm in no way a terraria expert though so correct me if i'm wrong. 1. External editors could maybe render the world for you 2. Sure thing, Minecraft is not "Theoretically infinite" either, but cmon, nobody likes a nitpicker. EDIT: people keep commenting about this one, oh boy. Apperently i need to be told 20 times. Minecraft IS NOT infinite, its borders are the mathematical limit of a signed 32bit integer. And yes i know now terraria has a fixed size aswell. What the guy ment was: its big and the worlds are randomly generated. 3. In Minecraft when you use a portal, the tiles on the opposite end get rendered, easy. EDIT : it doesn’t matter if Minecraft portals go to another dimension, same concept. Next example : Lets say water falls with 1 tile every half second and you take the example he gave for time spent away. I'm far away and when i'm back 10 minutes have passed. How much did the water fall down? Easy, (10*60)/.5 = 1200 tiles (max) this can easily be rendered. I'm not saying Terraria does this, i'm saying your example is bad. Mods can see it sure, does your game lag when you use that mod? 4. i guess so. He didnt mention it in the video, that does not make his video false (like you mentioned in the beginning of your comment). I don't know how much you know about terriaria's internal workings, but most of your examples can be debunked with a simple explanation, YES debunked mr “you didn’t debunk anything”. Hence my comment.
@@hayo7073 The invisible part of the world is only 4 blocks outward in all directions. Terraria mod and vanilla maps do not "enable" the tiles shown; they're always active.
1 - If the code to generate the world is known, then the external viewer can also generate the world, using the same algorithm as the game would. That means it could still be procedurally generated. 3 - Teleporters can load the other side as you go through. If you use a mod to keep those tiles active then the mod can keep them active as well as the player. That doesn't show the game will naively keep it active. He already explained how plants can grow off screen. The one interesting point would be water flowing. If you set it up such that water should flow a very long distance, place the water and teleport away (or outrun the water if possible), see if it still flows that long distance even though it isn't visible (i.e. wait that very long distance away and see if it flows to you). However it could also be a hybrid approach were some things work regardless, some only work when close to the player and some only work when they are being interacted with.
Just had a similar topic in my university, would love to see more content, as you talked about in the end of the video! Great work mate, awesome and easy to understand description!
he meant to say, every level is infinite as in every level can be different, ergo, infinitely generated. i thought the same thing, but it makes sense, but yes the world has a set size S - M - L
@@yalkn2073 I think what was meant in the video was that, in theory, the world's could be generated infinitely if there was no limit set to the world size. I assume the world's have a cap due to data and processing limitations when keeping track of that much terrain.
@@yalkn2073 infinite in the sense of, you will never see every seed because there are too many. is minecraft "infinite" no because it too has a border and a limited number of seeds but you will never see them all in your lifetime so its considered infinite
@@CatheteriZedEYE That's infinite seeds not an infinite map. In minecraft, the map is practically infinite as the time required to explore all of it in would be in centuries, while terraria's maps would require anywhere between a couple of hours and a few weeks, depending on map size and how much you focus on exploration
As someone who started his game coding days in the 80ies on a C64 all I can say is I'm completely amazed at how someone can be amazed that todays gaming computers are handling "thousands of tiles" in a 2D game without crashing, and would feel the need to make a video to explain this.
That's the real problem here. If all you know is Unity, you have absolutely no clue that that's child's play if you did it yourself. Growing up with ready-to-use engines is incredibly unhealthy for game programming, so much reeducation and unlearning to be done in the near future...
@@ExternetEx It's sort of an engine, but it's very bare-bones compared to Unity or other similar engines, and not really made for anything more than 2D which it does *very* well, clearly :)
Congratulations, i've never seen a video about how a game works where in the first 45 seconds they manage to convince me that they haven't even played the game before.
This is one of the best channels on UA-cam! I love learning the coding tricks you've talked about for portals and now here, please keep making new content :)
Pretty bad description. Your meant to send the block data to the gpu and make a single draw call per frame. Your making the cpu loop thousands of times per frame to make a draw call for each tile.
By block data you mean like pitch pixelmask and stuff like to instead change the pixels colour using vectors (I'm just trying to understand not saying you meant this, if I'm way off can you let me know) i know next to nothing of spritebatching if that's what it is
But he's just.. wrong. Find a better channel to learn these things, please. He's throwing terms around like 'frustum culling' without understanding the concept, and this video is misleading in so many ways
This video's information about how Terraria works is sadly nearly completely false, as many people have explained, but this was still very high quality and enjoyable
You don't need to chunk your tiles, and frustum culling is unnecessary for a 2D game with fake z-depth. With an efficient sprite batcher and tile renderer, you can iterate and draw the entire screen space of tiles every frame and still get thousands of fps. The thing that takes up the most processing time is the realtime lighting, which runs a flood-fill-based algorithm for every light emitting tile or object. This is so expensive that it can't run every frame on lower end machines, and either needs to be done in parallel or processed partially each frame until it's completed. (source: I've developed a custom engine which is meant to handle worlds similar to Terraria.)
Rendering millions of sprites at 60+ fps is nearly impossible. I've dealt with optimization before, and I can assure you frustum culling is absolutely necessary to optimize most games. In fact, one of the main reasons frustum culling is so common is because of how effective it is. I'll bet that the reason you don't need frustum culling for your renderer is because it's already doing it for you behind the scenes. However, Terraria uses its own engine, so it needs to do it manually.
@@GR-yu7gs I didn't clarify correctly. The culling isn't happening behind the scenes; it's my custom engine. I'm still only rendering what's on screen, based on the (orthographic) camera boundaries. It's just not technically frustum culling, which is meant for 3D. 1 million sprites is the max my engine can handle at 60fps on my PC. Normally, I'd never need to render over 100k.
When I was still working with XNA when XNA was still a thing, I made a (successful) attempt at a 2d tiled game prototype with several hundred thousand tiles. I simply made a single array with all the tiles and only rendered the tiles within my cameras bounds + a bit of padding and it worked great. For something like Terraria you definitely don't need huge amounts of optimization to get it to run well on modern hardware. Although through implementations of simple things like chunks, a huge amount of optimization cold have been obtained.
Terraria's developers made the game and only optimized where they NEEDED to. Which is the correct way of optimizing as early optimization can introduce painful and difficult to track bugs.
William Weissman in regards to making 2D tile games look tough to crunch, yes. it's the same simple logic that's been used since the likes of Mario. (1985 on NES) the only difference today is we can render much more polys on screen. the size of the world means nothing. they could generate an infinite world if they wanted. it's just data. it's not all loaded at once. lol like minecraft. which blows terraria's size away. and the total polys is much higher. "omg, how is minecraft not breaking the computer?! aaargh" **tries setting infinite render distance** bwahaha xD only a fool wouldn't recognize how stupid that is. and he literally mentions frustum culling. lol frustum culling doesn't come in at all for a grid of cells. that's just knowing your render region. lol you have direct access to what portion is in bound. (xz chunks / xy tiles) where frustum culling actually comes in, is when you don't directly have a way to just render what's visible. like with 3d polys. you literally have to check if it's inside the frustum. and the only way to do that is check a single point is within all the frustum planes. since doing that for the tons of poly's there are (especially with todays graphics) would be expensive, we just check a larger area that encapsulates all those poly's. meaning some couldn't be culled away. so some off screen poly's will be processed, and simply clipped away. and again about the poly count, a screen filled with tiles is nothing astounding. literally, the more there are, the smaller the polys are. lol example. say we made them 1x1. omg! 1920*1080 tiles?! how we gonna do that!? that sounds like too many pixels to me! xD while in 3D tons of these polys will be overlapping, so processing much more pixels. and they all need perspective correct interpolations for each pixel's attributes. and they all need translating/projecting with a 4x4 matrix. (16 multiplications 14 additions 4 assignments per vertex) whereas all 2D tiles need is basic xy shifting. (2 additions 2 assignments per vertex) basically, he should've done a video about minecraft. lol
@@DlcEnergy Except just because something you render is small doesn't mean it's not a performance hit. A major factor in rendering performance is draw calls, the actual pixel and blend operations you are talking about aren't usually that bad, depending on the complexity of the shader, even if you have a lot of overdraw. 2D games also need to be projected with a matrix, since clip space is 3D even for 2D games, only difference is you have 4 less vertices per object to multiply with the matrix. The actual performance difference between rendering a sprite and a cube is insignificant. All it comes down to in the end is how many objects you are trying to render. Instancing can play a huge part in reducing performance if you have a lot of similar objects.
Lym my point was that a larger count doesn't linearly increase how many calculations are needed. have you ever had so many 3d polys in the same location and wondered why they're so laggy (when up close) yet fine when spread out? (far away) because they're no longer tiny. translating them all is no big deal. the rendering has a much bigger affect. and for tiles (which we're talking about) is simply 2 additions. you don't need a matrix. we're not even rotating them. lol you're thinking of how the fixed pipeline of opengl makes you use its builtin matrices to project/translate. stop that. lol opengl is prioritized for 3d graphics. which is why we have the homogeneous coordinates. we can't project before clipping. (since it could divide by 0 or invert projection) we can't interpolate in 2d and expect 3d perspective. if all this trouble is powerful enough for 3d graphics, it'll be powerful enough for 2d anyway. and most modern 2d games would likely make use of most of it anyway. if they're gonna have rotation, they're gonna need tri's to do the rendering. but again, we're just talking about a simple tile game. do you think mario on the nes would've used matrices for some tiles? and translated 4 vertices for a square? and interpolated over 2 triangles to calculate the pixel? lol think efficiently. and ask yourself how you might do that. test your ideas and see your results. there's PBO's. there's glBlitFramebuffer. you can just upload the raw pixels to the buffer. and whala. no calculating over tons of interpolated texture coordinates for tons of triangles for no reason. and if you wanted some shader affects, you could just render the texture. of course if maybe you wanted wavy grass or something, then you'd render them separately. and if you didn't want to keep re-rendering all the individual tiles over and over, you could chunk it up. have a range of tilemaps. so as you explore more tilemaps are built quickly. and those larger pixel streams can be uploaded quicker. anytime a tile is changed, its tilemap is updated. yada yada yada...
I’m sure it would work the same as Minecraft where the game only loads up what’s in the screen and doesn’t load the other info until you turn around. That’s before actually watching this.
The world of terraria isn't infinite, I feel the credibility of the rest of the information is lost. This is a simple fact about the game's world and any research into it would reaveal that.
Theoretically infinite, not actually infintie. By changing the parameters of the world generation you can make it as large as you want (within the limtis of your computer) and not simply a scaled version. Fixing the map to a predefined size is one way to avoid that issue of so many tiles.
This video was my first introduction to your channel and I thought from reading the title that Terraria used some cool bitwise pipeline to optimise the tile rendering :/
Really liked all the points you raised, and you explained them super well. The tree analogy was awesome. As someone that got into codding some, and loves game development, I would have had a totally different approach to it: First, instead of having tiles perform actions every frame, I would have entities perform actions. So the tiles would be stored in a arrays, one for each chunk, and entities would be handled separately. The blocks would have properties and methods, like HP, but they don't update on their on so they are not iterated through. Then I would have a an entity list, that is iterated through periodically, which contains things like trees, enemies, etc... And those would be capable on calling on methods periodically. Though I might have different update methods getting called whether they are in a visible chunk or not, and then just have the engine go through a list of lists of entities per chunk calling either "light update" or "heavy update".
you can straight up ignore the part about frustum culling- that's only for 3d games. For most 2d games you don't actually need tricks to save on performance. I'd recommend ignoring this dude
I love these. Because maybe I wanna build a game. But I want to add an element. These videos give me so many ideas and ways of looking at these problems. These vids are gold. Can't wait to see more.
I just saw this video is years old, but I wanted to point out that I'm pretty sure Terraria's NPCs also load several chunks around them as they can be killed when you're not around them
You didnt mention sprite batching, which is really the main way they optimize their tile rendering because in modern opengl, drawing something to the frame buffer, isnt the same as rendering it to the screen. You can combine all the tiles into one big model and succesfully render all the tiles in one draw call
I love your work man, Thanks for Coming back. Here are few more things we do to optimize these type of games. Using Atlas is very crucial so we don't have to change texture. An array of Similar tiles is combined into 1 tile, with bigger size and multiplied UV. Static Mesh of Multiple Tiles are combines into One mesh, to hugely reduction in draw calls.
Hey, I don't know if you will even read this, given your inactivity, but I'm still really grateful for your clear explanation of this topic. I'm really inexperienced when it comes to programming of any kind but find this stuff quite fascinating! It's a shame you didn't follow up with the Procedual Generation part though, as others would agree. Hope you'll come around to do some some day. I'll just leave a sub for now. :) EDIT: Maybe if you still have a script for that video you could also just release that on it's own. I think it would help a lot of people understand the technical part!
"grateful for your clear explanation of this topic" the guy didn't explain this properly at all, threw in concepts and comparisons that don't make sense, and just... don't listen to him. He doesn't understand what he's talking about.
There are further optimizations. They're a little complex to explain just by typing here, but I'll do my best: 1. Don't check every chunk of tiles. Instead, keep track of all interactive objects (player, enemies, trees) and their position, that is, the index/id of the chunk they're currently on. So, for example, if player is on chunk 3, you know that you only need to update this chunk and can ignore the others 2. The second optimization is called dirty rectangles. It takes advantage of the ghost effect caused when you don't clear the screen. Basically, you draw all tiles once and then you never clear the screen again. After that you only draw the tiles that changed on top of the old ones. The tiles that didn't change will remain there since you didn't clear the screen. The only problem with this technique is when you need to scroll the screen, and this leads to optimization 3 3. If your graphics card has enough memory (this is the case nowadays), instead of drawing the tiles directly on the screen, you create a large image on the GPU memory with the size of your whole scenario. Then you draw all the tiles in this off screen image once, and every time the game updates you draw the updated tiles on this image. Finally you make one single call to the GPU to draw this image on screen. Since the off screen image is larger, you can only draw a portion of the image on the screen (operation known as blit). By chosing a different portion of the image each time, you create a virtual scroll effect. Also this technique improve performance because the GPU is much more efficient on drawing a single large image than drawing many small images. However, with procedural generated scenarios like Terraria, it's not possible to fit all the scenario in a single off screen image. This leads to optimization 4 4. Instead of drawing a single huge off screen image, which can actually degrade performance if the size of the scenario is too large, you can subdivide the scenario in several images/sections. So, if you have a viewport with 1920px width, you can create an off screen image with 5760px width. If you center this image on screen, you will have 1920px displayed, plus 1920px hidden to the left and 1920px hidden to the right. This way, you can scroll the screen for both sides with very little impact on performance because that part of the scenario is ready, you just need to show it on the screen . Now, suppose that the player starts walking to the right, after he walks 2880px, it will be in the right edge of the scenario. This is the moment when you can generate the next section of the scenario and draw it to another off screen image with 5760px. So, if the player walks to pixel 2881, you stop showing the previous off screen image and start showing the one you just created. Repeat the process ifinitely 5. This final optimization is not related to drawing things on screen, but is related to the way you update the game state. Generally you create objects on your game, update them, draw them on screen and once finished you destroy them to free memory space. Now, this technique is called object pool and consists of keeping your objects on memory instead of destroying them. So, suppose you have an enemy that comes from the right of the screen to the left, like the goompas on super Mario. You create the enemy, set it's position to the right edge of the screen and on each frame you move it some pixels to the left. When the enemy passes the left edge of the screen, instead of destroying it, will just reset it's position to the right edge of the screen. On the player's perspective it seems a new enemy, but it's just the old one. You can change, it's position, speed, sprite and many other properties to make it seem a completely different enemy. The secret here is that creating new objects is much more expensive for the CPU then changing the existing ones. For a few objects you may not see difference, but for hundreds or thousands of objects this can have a huge impact
@Badog98 I didn't say it increases speed with more tiles. I only really said that the method shown in the video doesn't explain real Terraria's behavior.
Great video. There are plenty of similar videos catering to us seasoned devs, but I love how you took the subject and made it accessible to the average gamer who may not have any programming background.
Why do people always say "fry" your computer. Computers only "fry" under very specific circumstances, and playing a demanding game is definitely not one
Why do people say downing in money? It's impossible to drown in paper. Because it's a saying, somthing that just developed over time, people don't actually mean it fried their computer, it's just another way of saying the computer shat itself
Plexy_ Glass no. Frying a computer mean it’s won’t work anymore, like if you shock your motherboard. Playing a demanding game will crash your software or your computer but it won’t be fried/bricked.
@@snoopy7156 you could likely destroy your computer by running a demanding game, GPUs and other computer parts can burnout from overuse or working them too hard.
3 роки тому
@@thedarklordx Did you ever see a computer since 1990? Every component in the system since the 2000s will protect itself and shutdown if overheated.
I like how when you needed something to be happening in the background while you spoke you decided that killing a crimera with a bronze pickaxe was the content you needed
Hilarious how the UA-cam algorithm sends me a pretty high quality video, then I go to subscribe to the channel, only to find out it's been inactive for two years. Then I go into the comments to find out that the recent recommendations have inspired the estranged creator to continue his work. It's a pretty uplifting story actually and it makes me excited to see more of your content in the future : )
First: I never questioned it cause computers are big ass machines doing trillions of calculations per second. Second: My computer can't run terraria at 60 fps.
@JamBixX Do you actually know anything about Game Design or are you just salty because he didnt play Terarria? Spoiler Alert: Terraria isnt what this Video was primarily about. So either start being constructive or GTFO
i mean, some quick math and you see that even on the biggest map size, assuming each tile is a byte, that'd only be 20mb of data, which really isnt that much and yeah, even with some more data per block, you wouldnt exactly hit the modern ram limit of 8gb.. or even 1gb and rendering.. thats way way simplier, just render whats on the screen...calculate which tile is on the top left corner, and the bottom right corner, do a nested loop and draw, also some other math to offset the player position by the blocks to add 0-16 pixels
@@alyx8815 well, basically.. lets say that terraria only had (a maximum of) 255 diffrent block types, for example dirt = 1 stone = 2 wood = 3 that means we could represent each tile/block with 1 byte (since a byte can store a number that ranges from 0 to 255) now, the biggest terraria map ( terraria.fandom.com/wiki/World_Size ) is 8400 tiles wide and 2400 high, multiply those togheter and we get how many tiles/blocks are in a whole large map 20'160'000 blocks, and if you give 1 byte to each block, thats 20 mb, so it would take 20 mb's of ram to story that much information now terraria problably stores other information for each block too, so you might need to multiple the ram usage a few times, but even still, its not that much ram for a modern computer and regarding rendering, well.. you can calculate which blocks are gonna be inside the screen by figuring out.. well, which blocks should be in the corners of the screen (depending on camera and player position and zoom) and then just draw all tiles in between not sure if this explanation was better or worse than my original comment but yeah ^^
@@EnderCrypt Thanks, this was a huge help! Memory was the first question on my mind when he started talking about storing data for that many tiles, which he didn't clarify in the video.
1. Terraria might not have pixel perfect design, so just because I tile is drawn in 16px doesn’t mean it takes 16px on your screen. It might take more which means less tiles to draw = less work. 2. Drawing 8,000 sprites at 60 FPS is no problem at all. Computers today can perform over a billion operations per second. Billion / (8000 * 60) = ~2000. A computer can definitely draw a single sprite in 2,000 operations. Of course, there are other things happening, but a billion operations per second is on the low side. But this graphics stuff is usually done through parallel processing with dedicated hardware meaning each sprite can be drawn at the same time, taking less processor time overall. 3. 2:50, so you’re assuming that in terraria each tile has its own functionality and you put that in the draw call for some reason. I think it’s reasonable to say that the tiles in terraria are mostly static. Dirt does not need it’s own functionality until the player interacts with it. There are some elements which do have their own functionality, like growing plants, but that doesn’t mean that each is an object, running a timer until a random time when they grow. More likely, the game selects a couple tiles per frame at random. Eventually the plant tile will be selected in random time. This is how Minecraft works.
This video is not complete. You see, sure, the "store timer" trick works for trees and crops, but doesn't work for corruption because corruption SPREADS. So corruption blocks HAVE to be enabled every X ticks even when they are off screen so it can properly simulate the corruption growth. The timer trick would only work if the growth is completely deterministic.
Seems like you haven't played much of Terraria, because most of what you say is false and doesn't refer to the actual behaviour of Terraria's game engine whatsoever.
CHUNKS!!1! One of the fist things that I try to create once a start to learn programing was make a terraria clone,and boy did a learn fast, realy fast that you cant just create a shit tons o tiles and expect to not have a 0 fps game on hand hahaha,and my approach to procedural was nothing but give a randon(-3,3)*16 to the Y coordinate of the fist tile,than fill all tile below,no caves,nothing,just a mass of tiles running at 1 fps hahahaha,I did improve a lot now that I think about it :D,amazing video,sad that the channel dont post any more =/
and now imagine 3d world "tiles" which are pixels of textures of 3d objects which are basicly 2048px each and can be repetable on 1920x1080 resolution. and now imagine 4d.
And most important: Terraria doesn't use Unity3D which is quite slow (I've heard the new ECS is faster). A few years ago I compared rendering a lot of sprites. While pixi.js (a JavaScript Rendering Framework) handled 30k Sprites and libgdx handled over 50k, Unity3D FPS dropped below 25 with just around 5000.
Who is asking this question? There's not 1000s of tiles on screen all the time, they could all share the same texture and many of the tiles are repeated (instanced), the geometry is the same and with it being tile based positions are highly predictable and easy to compute. It's not like the game is renderimg multiple complex 3D models with high Res textures and tons of particle effects, AA post processing and other complex effects. The GPU is massively parallel so rendering a couple thousand small tiles mostly all in sequential order (certainly all in a grid) with the same geometry and potentially using the same texture really isn't a very impressive feat. I've managed similar performance (without other fancy effects) without any batching as I was using SDL to render which did individual draw calls. Your graphics card may even have a CUDA core for each tile on screen at lower resolution so 60fps would be easy to achieve.
Game devs are asking this question and if you aren't, maybe you're missing something. Rendering the tiles isn't the hard part, it's actually handling all the tile data of every tile in the world at the same time in real time. A large Terraria world is 8400 x 2400 and contains 20160000 tiles that need to be handled. Data that needs to be handled includes tile type, id, position, collision,, as well as other things that update real time such as growth for plants such as blinkroot or moonglow, grass growth, vine growth, corruption, crimson or hallow growth, chlorophite growth, etc. Terraria needs to be able to calculate all this at the same time. What the video mentioned about the tiles saving the time last on screen is still not true, as proven because we can see that grass has grown further out on a dirt plane, which is impossible for the time method because the tiles further out would not be able to update because the tile with the time data has not been loaded in yet. This theory was disputed by an ex-Terraria developer on the Reddit post for this video. Keep in mind that Terraria is very capable of running at 60fps on low-end machines that may only run on integrated graphics and with only two cores for CPU, and that Terraria was first released all the way back in 2011, when computers were definitely not as powerful. Here's a link to the Reddit post, and Solsund is the developer who worked a bit on Terraria. www.reddit.com/r/Terraria/comments/63b7h4/how_does_terraria_handle_thousands_of_tiles/
@@ramennnoodle Chunk based is nothing new and based on things I've done in the past I'm still not overly impressed however I've never ran terraria on really low spec hardware however I've run 3D demoes on very low spec hardware rendering 1000s of triangles at high frame rates. I don't see any issue with the method mentioned in the video for updating.
@@ramennnoodle I'd say also that if these Devs are really struggling to get their games to come close to this performance then they are missing something be it rendering techniques or perhaps the issue is more to do with data locality and making their map formats a bit more cache friendly. Games are hard to make efficiently but there are many known techniques and optimisations available if people are willing to research. I've certainly had terraria lag a small amount when playing multiplayer on a fully wired LAN so there was no connection issues and only 2 players.
I'm pretty sure Unity can handle it with good optimization. But I see your point. It has a pretty large overhead as it is. Very simple shaders can help, going with forward rendering path or even vertex lighting also does a good job. Generating chunks, storing them as images, and regenerating them on runtime also does a good job. Long list of optimization and simplification.
As several people have pointed out, this video is a wrong representation of how Terraria actually works. It turned out to be more of a discussion of my own ideas and solutions. I am sorry for spreading misinformation.
The inaccuracies were neatly pointed out by user Mirsario, who I will quote directly to lay out all the mistakes I made in the video and their rectifications. Thanks Mirsario (and others) for taking your time to point all of this out.
"
==Relation to Terraria==
1:00 - It doesn't keep track of anything. They just sit in memory, this is not a physics simulation. There are also really not a lot of tiles, the "Large" world size is just 8400x2400.
2:16 - Your Unity3D object-oriented rendering has nothing to do with Terraria, XNA, and its SpriteBatch rendering. It wouldn't have been possible for the game to render so slow in the worst of the worst cases.
Additionally, the game only renders tiles 12 times a second, rendering to a texture.
2:45 - No, the game has no object-oriented tile logic. Nothing in it is object-oriented, actually. And that's a good thing for tiles. Your idea is really, really bad.
3:54 - Frustum culling is a 3D technique that has nothing to do with 2D and non-object-oriented designs. Like the ones Terraria spams tons of. Cutting off off-screen stuff in 2D is nothing but a check for rectangle bounds, which is hundred times faster and simpler.
4:48 - Chunks? Yeah, Terraria has none of that. At all. It never did. It just uses a giant Tile[,] array, which is idiotic, but works for vanilla version of it.
5:13 - "If a tree falls in Terraria and it isn't happening on screen... Does it still make a sound?" Yes. It tries to.
5:37 - Yes, all tiles are active at all times. Trees grow when they grow. Only multiplayer clients don't get all world data immediately, and that's all.
The way these trees grow is not through some magic object-oriented Tile.Update() calls (no methods like that exist), but through the world's update method, which, again, idiotically, picks like 1000 (depends on world size) random positions every update to do various logic like that, like spreading grass onto dirt if the randomly picked tile is grass.
5:56 - This has no correlation with the game. You could also at least say to store your made-up timers in your made-up chunks.
" - Mirsario (altered slightly)
Additional points made by Fevix Darkwatch:
"
1) Terraria is in no way procedurally generated as you play. The moment you first spawn in, before you've even taken a step, you can exit, load the world in an external editor, and view the entirety of the world, from corner to corner, which brings me to....
2) There are NOT "Theoretically infinite" tiles in Terraria. Each map size (Small, Medium, and Large) has a hardcoded height and width. You can very easily reach all four edges of the world. The sizes can be seen here, along with total blocks available: terraria.fandom.com/wiki/World_Size
3) Tiles don't activate/deactivate based on distance to the player. Teleporters can work across the entire world's width even without another player standing near the other end. Water falls, even offscreen. Trees grow on their own, even hundreds of blocks away. This can all be seen by using a mod to constantly reveal the entire map ingame while it's running, allowing you to watch from a distance as trees, plants, grass, and water all moves without any players nearby. Terraria uses its own custom engine which can only do one thing, but it does it very, very well: Run Terraria. Blocks don't keep track of their status constantly, either. When a player starts mining a block, THAT BLOCK starts keeping track of its status to determine how much damage it's taken (Better picks do more damage) and when it reaches a threshold it breaks and drops an item. When a block isn't being interacted with, it's pretty much inert, doing nothing and contributing no load aside from render.
4) In addition, you can save a LOT of rendering time by using a buffer of sorts. Render the visible area once, apply a lighting filter layer to darken areas that aren't lit (or color areas that are lit with a colored light), and saving that render somewhere, optimally in RAM provided it's small enough. As the player moves, chop off bits that fall off one side, and render only the bits that come in from the side. Re-render a small area around tiles that get updates (Trees growing, grass spreading, block mined) and boom, instead of rendering thousands of tiles per frame, you only have to render a couple dozen unless some massive changes are happening, EG someone just released a giant flood of water into the caves.
" - Fevix Darkwatch (altered slightly)
Some more broad points made by Mirsario:
"
==How useful this is to game developers==
First of all, he brings up an issue that's not real anywhere but in his example, which is him using OOP Unity rendering without any real batching.
The way XNA's SpriteBatch (which Terraria uses) works (in immediate mode, which avoids sorting) is by creating a buffer (you can think of it as a mesh/3d model created for just one frame), and putting vertex data into it. Then it's all uploaded to the GPU with one call and drawn with another. It's all really quick.
The way Unity3D rendering works is, like in any 3D engine, by storing data about what needs to be rendered, then sorting that data, then doing a draw call per mesh in just an optimized order (to avoid frequent calls that switch shader programs, but not to avoid draw calls). These sorting optimizations only hurt us with such hierarchies, as they're a very good example of optimizations with trade-offs. Unity3D does have batching, but only for objects marked as static, and he clearly didn't use that.
So, rendering optimization has never been an issue to begin with, with something so simple as Terraria (or any game like that with a finite world, that is, Starbound too).
Then he brings up frustum culling. I've already mentioned how unrelated this is. Let's just say that it's another overhead for his 'issue example'.
Then, he talks about object-oriented designs on tiles. You don't do that. This is not a physics simulation, and if you want to make one - please use GPUs, not CPU.
Object-Oriented-Programming is amazing for humans, but not for CPU performance. If you're doing C#, then please only use structure and not class Tiles (which Terraria did use, very stupidly, as it's just more memory usage and more stress for garbage collection). C# 7's ref variables have made structs like that a blessing to use.
Now, if I ignore the design shenanigans, the time comparison for when tiles get loaded sounds like a sane way to have freezable logic, but only if you don't plan on updating a tile 1000 times because it was unloaded for 1000 ticks, AND ONLY if timers are placed on chunks, not on tiles. That'd be an extreme optimization with zero cons, and missing it shows his mindset. Or the April 2, 2017 him. Programmers evolve, and I can't say that I wasn't a total pushover 5 years ago.
This really does only work with chunks, because for many operations you will need to know information about adjacent tiles. For simple grass spread, you'll need a system that can load neighboring chunks at chunk load distance's corners, without updating them unless they move into the real load distance. Sigh.
I have recently worked on making a 2D game (on my own engine) with an infinite world (this guy's weird designs suggest that they're about infinite worlds), and I have to say:
The only optimization needed was about generating chunks (No matter how fast your noise is, it's never fast enough), their saving & loading code, and their textures (but that only requires writing something that's like XNA's SpriteBatch, if you're just on that engine - this is not a problem).
This vid is really a bunch of made-up issues and incompatible made-up solutions.
If this is anyhow about recommendations to game developers - it'd be superior to actually describe how Terraria works, and advise against many of its points, as it works, quite frankly, idiotically* at many points**. Terraria only works well because the issues stated in this video are not issues at all. They just don't exist.
* - Re-Logic members do know, and perhaps 1.4 will rewrite many points, but it's not financially viable for them to do, as some once said, which is agreeable.
** - but it runs fine for what it is. As someone else in this comment section approximately said, this game is written to be nothing more but this exact game.
" - Mirsario (altered slightly)
Good to know the truth !
You've made a mistake when you forgot to mention that it was your ideas and not the actual solutions in terraria but, hey, making a mistake is ok as long as you admit (and you did)
You should totally remake this vidéo!
Much respect for keeping a level head and pointing out all the corrections these guys made, thats an amazing skill that very few people have!
thank god you finally came out and said this I was getting annoyed at arguing in the comments lol
@HuffmanTeamGaming why would he do that? Doesn't it take views away from his channel? Also this video can bring in more people that can watch his newer content, which is correct, as far as i've seen. It's pretty hard tp miss the big "redacted" in the title
@HuffmanTeamGaming Clearly a lot of work went into this video, and although it may not be accurate to what terraria actually does, it still shares some awesome ideas and solutions to various problems in games, and honestly he probably wouldn't even have to change the title if he just pushed it as how he would do it, as opposed to how it is done.
Wow, what happened? Two years after I stopped posting the youtube algorithm comes along and now this! :D
Guess it's time to start working on that procedural generation video! Thank you all for the kind comments!
Since 2017, this channel has since been sort of an abandoned project of mine. I can't lie.... that really makes me want to make new content.
Yes please!
do it :)
Sure, do it
We need it please
UA-cam recommendations caught on I guess, haha.
Still waiting for the procedual generation video :(
@@rechronicle some here! excellent channel
I'll PAY for it! C'MONNNN!
Terraria world generation is a lot simpler than Minecraft's, etc. since it is a closed world (Not procedural!)
Terrain: 2D Perlin/Simplex noise. Caves are a lot more complicated though
Trees: I've made an algorithm for spacing them out and I'm not sure what Terraria does. What I do is check if a noise value is greater than the 3(+) values around it
Ores: For every chunk (Like 64 size) spawn a random amount of ore patches
Stuff like temples, pyramids, and the dungeon probably have much more complicated algorithms that I would not know about
@@nathan44u it is procedural
@@ffccardoso The entire world is generated when you create the world. There is no way to adventure past the oceans
You wanted exposure; 2 years later, the Algorithm fulfilled your request.
The Algorithm has spoken.
Yea and still as today
"I'd love to see you in the next episode"
me too, me too
Max Pikhteryev :(
Look at his channel banner. New videos will come
Put this man in the next episode.
Why is this channel no longer active. It’s so good.
OMG. its such amazing channel.
I've just found this video thanks to the YT algorithm and the whole idea of disecting games sounds amazing.
Yeah that sucks, this video is really interesting
@@deamooz9810 yeah
Yes...
God, this video is a joke. There are so many things wrong, that I've split the following into 2 parts. Please read everything if you have the stamina, otherwise, well.. hm.
==Relation to Terraria==
Nothing in this has any correlation with the game. Things aren't as good, and aren't as terrible.
1:00 - It doesn't keep track of anything. They just sit in memory, this is not a physics simulation. There are also really not a lot of tiles, the "Large" world size is just 8400x2400.
2:16 - Your Unity3D object-oriented rendering has nothing to do with Terraria, XNA, and its SpriteBatch rendering. It wouldn't have been possible for the game to render so slow in the worst of the worst cases.
Additionally, the game only renders tiles 12 times a second, rendering to a texture.
2:45 - No, the game has no object-oriented tile logic. Nothing in it is object-oriented, actually. And that's a good thing for tiles. Your idea is really, really bad.
3:54 - Frustum culling is a 3D technique that has nothing to do with 2D and non-object-oriented designs. Like the ones Terraria spams tons of. Cutting off off-screen stuff in 2D is nothing but a check for rectangle bounds, which is hundred times faster and simpler.
4:48 - Chunks? Yeah, Terraria has none of that. At all. It never did. It just uses a giant Tile[,] array, which is idiotic, but works for vanilla version of it.
5:13 - "If a tree falls in Terraria and it isn't happening on screen... Does it still make a sound?" Yes. It tries to.
5:37 - Yes, all tiles are active at all times. Trees grow when they grow. Only multiplayer clients don't get all world data immediately, and that's all.
The way these trees grow is not through some magic object-oriented Tile.Update() calls (no methods like that exist), but through the world's update method, which, again, idiotically, picks like 1000 (depends on world size) random positions every update to do various logic like that, like spreading grass onto dirt if the randomly picked tile is grass.
5:56 - This has no correlation with the game. You could also at least say to store your made-up timers in your made-up chunks.
If you're a C# programmer, DigiDigger (that's only an assumption based on you using Unity), then why didn't you just decompile the game and have at least a single look at it? ILSpy and dnSpy can easily let you do that.
==How useful this is to game developers==
Even if we ignore this being about some game, his designs aren't optimization.
First of all, he brings up an issue that's not real anywhere but in his example, which is him using OOP Unity rendering without any real batching.
The way XNA's SpriteBatch (which Terraria uses) works (in immediate mode, which avoids sorting) is by creating a buffer (you can think of it as a mesh/3d model created for just one frame), and putting vertex data into it. Then it's all uploaded to the GPU with one call and drawn with another. It's all really quick.
The way Unity3D rendering works is, like in any 3D engine, by storing data about what needs to be rendered, then sorting that data, then doing a draw call per mesh in just an optimized order (to avoid frequent calls that switch shader programs, but not to avoid draw calls). These sorting optimizations only hurt us with such hierarchies, as they're a very good example of optimizations with trade-offs. Unity3D does have batching, but only for objects marked as static, and he clearly didn't use that.
So, rendering optimization has never been an issue to begin with, with something so simple as Terraria (or any game like that with a finite world, that is, Starbound too).
Then he brings up frustum culling. I've already mentioned how unrelated this is. Let's just say that it's another overhead for his 'issue example'.
Then, he talks about object-oriented designs on tiles. You don't do that. This is not a physics simulation, and if you want to make one - please use GPUs, not CPU.
Object-Oriented-Programming is amazing for humans, but not for CPU performance. If you're doing C#, then please only use structure and not class Tiles (which Terraria did use, very stupidly, as it's just more memory usage and more stress for garbage collection). C# 7's ref variables have made structs like that a blessing to use.
Now, if I ignore the design shenanigans, the time comparison for when tiles get loaded sounds like a sane way to have freezable logic, but only if you don't plan on updating a tile 1000 times because it was unloaded for 1000 ticks, AND ONLY if timers are placed on chunks, not on tiles. That'd be an extreme optimization with zero cons, and missing it shows his mindset. Or the April 2, 2017 him. Programmers evolve, and I can't say that I wasn't a total pushover 5 years ago.
This really does only work with chunks, because for many operations you will need to know information about adjacent tiles. For simple grass spread, you'll need a system that can load neighboring chunks at chunk load distance's corners, without updating them unless they move into the real load distance. Sigh.
I have recently worked on making a 2D game (on my own engine) with an infinite world (this guy's weird designs suggest that they're about infinite worlds), and I have to say:
The only optimization needed was about generating chunks (No matter how fast your noise is, it's never fast enough), their saving & loading code, and their textures (but that only requires writing something that's like XNA's SpriteBatch, if you're just on that engine - this is not a problem).
This vid is really a bunch of made-up issues and incompatible made-up solutions.
If this is anyhow about recommendations to game developers - it'd be superior to actually describe how Terraria works, and advise against many of its points, as it works, quite frankly, idiotically* at many points**. Terraria only works well because the issues stated in this video are not issues at all. They just don't exist.
* - Re-Logic members do know, and perhaps 1.4 will rewrite many points, but it's not financially viable for them to do, as some once said, which is agreeable.
** - but it runs fine for what it is. As someone else in this comment section approximately said, this game is written to be nothing more but this exact game.
I do understand some people's point that it was an interesting video to watch when you know that most of it is wrong, but not everyone does, and the fact that it's not mentioned anywhere that it's nothing but a discussion of his own ideas makes it awful content. The ones interested in this channel wouldn't be against DigiDigger's content becoming better, from either more research (or ANY RESEARCH, GOD!), or a different presentation that mentions when something (in this video's case that'd be everything) is speculation.
DigiDigger, if you did read this - do reply.
i'm just leaving a reply in the hope that it bumps your comment up in the list, mirsario
Thank you for saving me from deception.
EXACTLY!!!
Yes this is not how terraria does it but this video does teach optimisation so it's more a tutorial on optimisation so it's more mislabeled. I wouldn't call it a joke but more a tutorial
@@eliaslamsa6541 -I have replied to someone else making basically the same point as you in another comment branch. Can't really link it since I'm typing from a phone, so I'll just copy-paste it, but it's another wall of text, beware.-
EDIT: Merged that other comment with my previous one.
0:42 uhhhhhhhhhh
this guy know what happens when you get to the ocean?
Scrolled to the comments the moment he said that
It is procedurally generated. It uses an algorithm to make a new map each time as opposed to manually building the map.
@@Sniper0502 well he implied that the world was endlessly procedurally generated
@@Sniper0502 the size is predetermined (you pick it before the world is generated)
Minecraft: "procedurally generated" Terraria: "procedurally pre-generated" (confusion solved. lol)
many of us have misinterpreted "procedurally" to mean "on the fly". there's no shame in it. because what it actually means is kind of redundant. "using procedures". doesn't "generate" already imply there'll be "procedures"? lol so anyone thinking of something distinguishable would think of "on the fly" / "bit by bit".
This video oddly tries to make this harder than it actually is. Drawing tiles is one of the easiest tasks your computer can do. But if you use Unity engine to showcase that obviously it will seem as if thats something demanding, not because its hard, but because Unity's graphics pipeline is simply not built for that.
When you actually code your own renderer however, rendering let alone thousands, even millions of tiles can easily be done in real time with proper instancing. And you can easily use instancing on a game like terraria. So yeah, Terraria isnt exactly a game that is difficult to render unless coded horribly.
On a game like Terraria, if you are coding your own renderer, you can render all blocks of same type in a single draw call. Draw calls are the real performance hitter. You can reduce thousands of draw calls to less than a hundred.
Also, using atlas maps is a life saver
Actually you can also do that in Unity without problems. But you are right, it's all about how you implement it.
additionally, actually compiling the game helps with framerate.
Yeah, unity is focuses on 3d more than 2d, not saying you cant make a good 2d game
Exactly. Even the dumbest, simplest possible implementation won't run into any performance problems for a game like this. Assuming one texture atlas, 10,000 tiles on-screen, 6 vertices per tile (2 triangles, no index buffer for simplicity), vec2's for position and texture coords, that's 10000 * 6 * (2*4 + 2*4) = 960,000 bytes, less than a megabyte of trivially computable data. Just toss that data into a single vertex buffer and upload it to the GPU every frame, problem solved.
I can't wait until the 8th Bitwise video so that we, the viewers, will become a byte wiser altogether
There wasnt a video for 2 years, this is the last
Find a better channel to follow, please. This guy doesn't know what he's saying.
@@willtheoct Why are you so salty
last video: 2 years ago
this comment: made 2 month ago
comment: digidigger loved 2 month ago
*hes alive*
@@kicklemon1948 cause he gets a giant ego-boost from pointing out other's mistakes. The worst thing is, it's not even like other comments, which constructively point out why the video is basically all false, he went around commenting "FinD A BeTteR ChaNnEl"
"how many tiles are in the map of terraria, well, theoretically there are infinitely many"
no
thats not how it works
This suddenly got reccomended to a lot of people?
Yup
Yep
Yip
ye
This and UnboxTherapy getting dragged ruthlessly into the thorns.
"How does Terraria handle thousands of tiles?"
"It doesn't run in Unity!"
@Chickentenders A bad developer blames the tool. I've played unity games that run like ass and I've played unreal games that run like ass. It's just that there are more inexperienced developers using unity as it's easier to develop for.
that's how the video should have went tbh just "how does terraria handle so many tiles?" "it doesn't run on unity" "thank you for watching the video, see you around next time!"
@Chickentenders Unity is a great engine that since it has a freeware version a lot of shity games are done with it, a game like Escape from Tarkov is made in unity and runs amazingly well.
@Chickentenders Developers suck at optimization. I've played more laggy Unreal games than Unity games, just about any engine can create a game that runs smooth as butter, it's simply down to the skill level and amount of effort put in by the devs.
Use Unreal.
I thought I am about to get some interesting insight into how Terraria works... not even close.
BaseFook What do you mean?
@@villager1831 This video was like wild guesswork, for a problem that didn't exist, and doesn't even hold up in the context of Terraria. 8k tiles on screen? why ever would that lag? or fry your pc? or crash?
If you only store the time a tile was last updated and then use the delta later, then why the hell does liquid in Terraria keep getting updated?
I don't understand why people like this video since it's just so wrong.
@@villager1831 None of what he described is specific to Terraria. In fact these techniques are bare minimum expected optimisation on every game (where applicable).
He also very clearly has no understanding of Terraria itself too.
Like, for example:
"The amount of tiles in a Terraria world is theoretically infinite." (not exact quote)
Like, WHAT? Terraria worlds are CLEARLY finite. There's even the world size options!
Terraria modder here. I’ve been working with this game and it’s inner workings for almost a year now, and a lot of things here aren’t accurate.
First of all, Terraria’s worlds are finite and are generated only once. I’m not sure how the conclusion that it was infinite was reached, but that’s one of the more obvious errors here.
Terraria uses a random tile update function to handle things like the growth of grass and crops, spread of biomes, etc. This happens randomly and can affect any tile. While I’m not sure how often it’s called, it can happen to any tile regardless of where it is.
Second, tiles are absolutely not updated every frame. Or, more specifically, when you leave them alone. Terraria uses a function to tell the game if a tile has been interacted with in some way, and it updates the tile appropriately. This includes things like liquids flowing, tile textures connecting, etc. If you were to modify a tile (let’s say by adding some water) without telling the game that the tile needs to be updated, it would just stay. (our water block in this example would float in mid-air and not flow) This is actually similar to what Minecraft does in some ways (although I have no idea how Minecraft does it). In Minecraft, if you were to add a sand block, for example, via a third-party editor or otherwise, it would remain in place until an adjacent block is updated. The example of updating a timer each frame as shown in this video does not apply at all to how tiles work. The total number of tile updates, due to this system, isn’t actually that large. The game would suffer if a lot of those took place at once. If you’ve ever tried to drain an entire ocean into Hell, for example, the massive number of updates the game has to deal with slows fluid processing to a halt and it takes forever for any liquids to update.
An exception to this would be tile entities, such as chests, which are updated each frame and can contain additional information and functions. However, there are usually relatively few of these in the world, so their effect on performance isn’t bad.
One more thing: Terraria was built around Microsoft’s (now discontinued) XNA framework, which is less of an engine and more of a useful set of resources and tools. Using it, Terraria contains it’s own graphics engine designed to handle the game’s graphics. It does not use any sort of engine like Unity.
Also he got rendering wrong. His 20fps is caused by the cpu making a draw call to the gpu for every individual tile. Probally a side effect of having every tile being a unity entity. Tile chunks should be stored in gpu memory with a single draw call per chunk
I felt like I found a diamond. But when I checked your last video, it was from 2 years ago :(
you didnt "find" it youtube found it for you
Yup
Just like how I didn't "find" that sock I was missing; it just turned out to be sitting on my table. But a box fell over so that I could see it, and I'm grateful that this happened.
Exactly like me.
Find a better channel - this video has errors and there are way better technical channels on youtube.
dO YOU GUYS FIND A GREAT CHANNEL JUST TO REALIZE ITS DEAD
Yeah, that's sad actually...
'great channel'? he compared the terraria tiles on screen to 8000 unity Game Objects which is just nuts- unity is over-engineered, so it's not surprising that 8k GOs could consume way more than 8k bytes and 8k flops,
put 3.5 minutes of fluff before attempting to answer the question,
had a bogus question in the first place(Q: how does terraria handle 8000 tiles on your screen? A: your computer does trillions of operations per second, why wouldn't it work?),
and is missing the real way to save on performance with tilesets(upscaling on the GPU after storing tiles as individual pixels in a texture),
Surely you can find better technical channels on youtube...
More notes:
-Frustum culling involves rendering boxes to determine if the high-quality mesh should be rendered, and this isn't at all like what terraria does. There isn't even a frustum.
-updating certain chunks every tick can save on performance, but for a game like terraria, it just isn't worth it. This wouldn't work on liquids like lava or water, either, which need to be simulated in real-time
@@null3377 what the hell is a micro operation
For channels, I would suggest computerphile at the least.
and this guy is a legend, but maybe not as entertaining: yt.com/channel/UCdmAhiG8HQDlz8uyekw4ENw
sadly I don't have any recommendations that both captivating and informational on computers. I can only say that this channel does not present real information.
Gotta agree with William here
@@null3377 You made that term up. If a 'micro' operation is 2 inputs -> 1 output on the hardware level, then what exactly is an operation?
Why are GPUs measured in teraflops? FLOPs stands for FLoating-point OPerations per second. Is a teraflop not one trillion floating point operations?
No one's going to be mad if you're wrong on the internet, and I don't think you should argue the point
For those who are wondering how terraria procedural generation works, since apparently he hasn't uploaded a video for it, I can explain it to you. I created a version of terraria for my AP computer science midterm project. Here's what I did:
- start with a seed. This will ensure same generation every time. When you want a random number, you input a seed, it does some calculations, and outputs a pseudorandom number based on the number you put in. So, what you can do is keep feeding the output of the random number to get a new one, and if you have the same seed it will always do the same "pattern"
- Next you want to sprinkle random stone blocks around your blank world, this will start off the generation.
- Then, for every tile, if there is a tile next to it, there is a random chance it will become a tile. Do this enough times and your world will now have clumps, then mountains. depending on how you check for tiles around it, you'll get different results. However, this is not how Terraria generates its terrain.
- After that, you can add water to all the empty tiles that are at or below sea level
- Then, add dirt to all the tiles that have air directly above it and stone directly beneath it, then each tile you set to dirt, set the other 3 directly below it to dirt, and the top one to grass.
- You do the same thing but for sand underwater.
- For ores, you can have a random low chance of generating one in place of a stone tile, and then a random chance for the ones next to it to become the same ore.
- finally, you want to add trees. Check every grass block, and if there is a large enough rectangle of space above it, generate a tree.
This method will do good, but will make a bunch of floating islands, which, if that's not what you want, you can use Perlin Noise at the start
Terraria doesn't have floating islands, instead, it has a ground and a cave system next to it. Here's a simple way to generate it using Perlin Noise:
- Start of halfway on the y axis and set a variable to your current y value. On the y value (let's call it y0), start at the very left and add a grass tile at that value, 3 dirt tiles below it, and stone all the way to the bottom.
- Do this for every block, but change y0 by an integer between [-n, n], where n is how steep you want the hills to get. for better results you can use Gaussian (normal) distribution to pick the change in y0.
- Any empty tile that is at or below sea level now becomes water
- For the caves, start at a random point in the cave and make a line to another point 5 tiles away in a slightly changed direction. Make a chain of lines a random number of times and that will be a single cave path. You can make any number of chains, chains can split like a tree, whatever, until you have enough caves.
- Next is to remove every tile that is 4 tiles away from any line, and this will make cave tunnels with a diameter of 8 tiles
- Next, you can fill some of the caves with water or lava, by random chance or by how high up the cave is.
- You make trees the same way, but since there are no floating islands, you don't need to check for tiles above it
This is an oversimplified way to generate it, but terraria is much more complex and adds biomes, buildings, dungeons, and a lot more things. It's called procedural because it follows a set procedure, or order, of things to generate. Hope this helps!
Thank you. I haven't been able to wrap my head around how this kind of thing works, and this has really helped.
Terraria does indeed have floating islands, they often contain a generated house with a chest of two
Every world in terraria has floating islands specifically added to it during world generation. Small worlds have up to 4 of them, and Large worlds can have up to 8.
terraria.gamepedia.com/Floating_Island.
I'll admit it doesn't have the KIND of floating islands you mentioned (Noise-generated), but it does most definitely have many above-ground clusters of blocks. I'm not going to pretend to know how Terraria's caves are generated, but the cave generation you described would make many samey caves, not to mention it doesn't account for the unique generation in certain biomes like the Underground Desert or the Underworld.
"I can explain it to you"
then later
"However, this is not how Terraria generates its terrain."?
Thanks for the tangential information I guess...
Looks like UA-cam decided to recommend a video from several years ago by a channel that has been inactive since said video to a whole bunch of people again.
This video should be full of "I think" asterisks, because many of your points are demonstrably false.
1) Terraria is in no way procedurally generated as you play. The moment you first spawn in, before you've even taken a step, you can exit, load the world in an external editor, and view the entirety of the world, from corner to corner, which brings me to....
2) There are NOT "Theoretically infinite" tiles in Terraria. Each map size (Small, Medium, and Large) has a hardcoded height and width. You can very easily reach all four edges of the world. The sizes can be seen here, along with total blocks available: terraria.fandom.com/wiki/World_Size
3) Tiles don't activate/deactivate based on distance to the player. Teleporters can work across the entire world's width even without another player standing near the other end. Water falls, even offscreen. Trees grow on their own, even hundreds of blocks away. This can all be seen by using a mod to constantly reveal the entire map ingame while it's running, allowing you to watch from a distance as trees, plants, grass, and water all moves without any players nearby. Terraria uses its own custom engine which can only do one thing, but it does it very, very well: Run Terraria. Blocks don't keep track of their status constantly, either. When a player starts mining a block, THAT BLOCK starts keeping track of its status to determine how much damage it's taken (Better picks do more damage) and when it reaches a threshold it breaks and drops an item. When a block isn't being interacted with, it's pretty much inert, doing nothing and contributing no load aside from render.
4) In addition, you can save a LOT of rendering time by using a buffer of sorts. Render the visible area once, apply a lighting filter layer to darken areas that aren't lit (or color areas that are lit with a colored light), and saving that render somewhere, optimally in RAM provided it's small enough. As the player moves, chop off bits that fall off one side, and render only the bits that come in from the side. Re-render a small area around tiles that get updates (Trees growing, grass spreading, block mined) and boom, instead of rendering thousands of tiles per frame, you only have to render a couple dozen unless some massive changes are happening, EG someone just released a giant flood of water into the caves.
I was hoping a real programmer would show up. I wanted to also add that in all likelihood, Terraria does not function like a true tile engine would where it draws each individual tile as separate objects, or tiles. Rather, the smart way to do it is to indeed have each tile exist as its own object derived from a C++ class, but it for the most part only exists as code. Each tile object knows its x/y position and what pixels are associated with it, but the way it draws itself is simply "bit blitting" itself to the buffer. Take a look at that first landscape shot of Terraria in the video - thousands of tiles, but only a handful of bitmaps that are unique. That makes it terribly easy to store in memory and very easy to blit the same square of pixels to the buffer over and over again. It's like if you wanted to stamp your name onto a letter your wrote and were going to write 8000 letters, you don't need a unique stamp for each letter. You can use the same damn stamp and just use it over and over again. Same with tiles. Each tile just has "bluesky" as a string in a variable and the engine knows that refers to a specific square of pixels in the "master tile image" that probably houses all unique tile in it. So, it's just bit blitting that same square over and over again for each tile even though there are thousands of the same tile. Even if Terraria did keep tiles "active" after they went off screen, that would still be pretty easy to do since they just have to exist as code. It's not like there is any drawing going on outside the screen, which is the most intensive process games do.
I would like to comment on a few(all) of your points, i'm in no way a terraria expert though so correct me if i'm wrong.
1. External editors could maybe render the world for you
2. Sure thing, Minecraft is not "Theoretically infinite" either, but cmon, nobody likes a nitpicker.
EDIT: people keep commenting about this one, oh boy. Apperently i need to be told 20 times. Minecraft IS NOT infinite, its borders are the mathematical limit of a signed 32bit integer. And yes i know now terraria has a fixed size aswell. What the guy ment was: its big and the worlds are randomly generated.
3. In Minecraft when you use a portal, the tiles on the opposite end get rendered, easy. EDIT : it doesn’t matter if Minecraft portals go to another dimension, same concept.
Next example : Lets say water falls with 1 tile every half second and you take the example he gave for time spent away. I'm far away and when i'm back 10 minutes have passed. How much did the water fall down? Easy, (10*60)/.5 = 1200 tiles (max) this can easily be rendered. I'm not saying Terraria does this, i'm saying your example is bad. Mods can see it sure, does your game lag when you use that mod?
4. i guess so. He didnt mention it in the video, that does not make his video false (like you mentioned in the beginning of your comment).
I don't know how much you know about terriaria's internal workings, but most of your examples can be debunked with a simple explanation, YES debunked mr “you didn’t debunk anything”.
Hence my comment.
@@hayo7073 The invisible part of the world is only 4 blocks outward in all directions. Terraria mod and vanilla maps do not "enable" the tiles shown; they're always active.
1 - If the code to generate the world is known, then the external viewer can also generate the world, using the same algorithm as the game would. That means it could still be procedurally generated.
3 - Teleporters can load the other side as you go through. If you use a mod to keep those tiles active then the mod can keep them active as well as the player. That doesn't show the game will naively keep it active. He already explained how plants can grow off screen. The one interesting point would be water flowing. If you set it up such that water should flow a very long distance, place the water and teleport away (or outrun the water if possible), see if it still flows that long distance even though it isn't visible (i.e. wait that very long distance away and see if it flows to you). However it could also be a hybrid approach were some things work regardless, some only work when close to the player and some only work when they are being interacted with.
The channel is dead boi
“How does Terraria not completely fry your computer?”
**cries in laptop**
Holy shit your comment got hearted, they're still alive!!!
@@the_pumpking_ *he's
@@the_pumpking_ yay
SHIT, SHIT, SHIIT, DIGIDIGGER IS ALIVE!
@@panos21sonic interesting he ignored the comment telling what he did wrong
Just had a similar topic in my university, would love to see more content, as you talked about in the end of the video!
Great work mate, awesome and easy to understand description!
Terraria's maps arent infinitely generating, they are finite and have a set size
he meant to say, every level is infinite as in every level can be different, ergo, infinitely generated.
i thought the same thing, but it makes sense, but yes the world has a set size S - M - L
@@CatheteriZedEYE No, he didn't meant that, you are trying to find an excuse. You don't call something infinite because it has variety.
@@yalkn2073 I think what was meant in the video was that, in theory, the world's could be generated infinitely if there was no limit set to the world size. I assume the world's have a cap due to data and processing limitations when keeping track of that much terrain.
@@yalkn2073 infinite in the sense of, you will never see every seed because there are too many.
is minecraft "infinite" no because it too has a border and a limited number of seeds but you will never see them all in your lifetime so its considered infinite
@@CatheteriZedEYE That's infinite seeds not an infinite map. In minecraft, the map is practically infinite as the time required to explore all of it in would be in centuries, while terraria's maps would require anywhere between a couple of hours and a few weeks, depending on map size and how much you focus on exploration
As someone who started his game coding days in the 80ies on a C64 all I can say is I'm completely amazed at how someone can be amazed that todays gaming computers are handling "thousands of tiles" in a 2D game without crashing, and would feel the need to make a video to explain this.
That's the real problem here. If all you know is Unity, you have absolutely no clue that that's child's play if you did it yourself. Growing up with ready-to-use engines is incredibly unhealthy for game programming, so much reeducation and unlearning to be done in the near future...
Keep in mind that Terraria uses a custom engine, which means less overhead than with an engine like Unity.
Custom engine? Last time i checked it used Microsofts XNA and its language is C# just like Unity.
@@ExternetEx XNA is not an engine. It's a toolset for making games.
@@AshesOfEther I see. I thought XNA had a foundation since it has helper tools like Unity.
@@ExternetEx It's sort of an engine, but it's very bare-bones compared to Unity or other similar engines, and not really made for anything more than 2D which it does *very* well, clearly :)
The mobile version is developed in Unity. I worked on it for 2 years, such a bitch to optimize.
Congratulations, i've never seen a video about how a game works where in the first 45 seconds they manage to convince me that they haven't even played the game before.
Oh boy, I can't wait to watch the next video!
*Last upload: 2 Years ago*
This is one of the best channels on UA-cam! I love learning the coding tricks you've talked about for portals and now here, please keep making new content :)
Pretty bad description. Your meant to send the block data to the gpu and make a single draw call per frame. Your making the cpu loop thousands of times per frame to make a draw call for each tile.
By block data you mean like pitch pixelmask and stuff like to instead change the pixels colour using vectors (I'm just trying to understand not saying you meant this, if I'm way off can you let me know) i know next to nothing of spritebatching if that's what it is
Such an underrated channel. Explaining in examples how the certain things works must be hard.
Keep it up man. Waiting for your new upload.
Reegly Well,
Some say he still waits to this day
But he's just.. wrong. Find a better channel to learn these things, please. He's throwing terms around like 'frustum culling' without understanding the concept, and this video is misleading in so many ways
@@willtheoct Can you elaborate?
@@Lena_M v=YIDbhVPHZbs&lc=UgxElWUm4kcoxqzrp014AaABAg
This video's information about how Terraria works is sadly nearly completely false, as many people have explained, but this was still very high quality and enjoyable
You don't need to chunk your tiles, and frustum culling is unnecessary for a 2D game with fake z-depth. With an efficient sprite batcher and tile renderer, you can iterate and draw the entire screen space of tiles every frame and still get thousands of fps. The thing that takes up the most processing time is the realtime lighting, which runs a flood-fill-based algorithm for every light emitting tile or object. This is so expensive that it can't run every frame on lower end machines, and either needs to be done in parallel or processed partially each frame until it's completed. (source: I've developed a custom engine which is meant to handle worlds similar to Terraria.)
Rendering millions of sprites at 60+ fps is nearly impossible. I've dealt with optimization before, and I can assure you frustum culling is absolutely necessary to optimize most games. In fact, one of the main reasons frustum culling is so common is because of how effective it is. I'll bet that the reason you don't need frustum culling for your renderer is because it's already doing it for you behind the scenes. However, Terraria uses its own engine, so it needs to do it manually.
@@GR-yu7gs I didn't clarify correctly. The culling isn't happening behind the scenes; it's my custom engine. I'm still only rendering what's on screen, based on the (orthographic) camera boundaries. It's just not technically frustum culling, which is meant for 3D. 1 million sprites is the max my engine can handle at 60fps on my PC. Normally, I'd never need to render over 100k.
Yeah, this youtuber isn't all that knowledgeable in this or Terraria.
This was interesting!
*Checks channel*
Oh......
RIP :(
Don't get technical info from this channel - he has no idea what he's on about
@@willtheoct Don't get technical info from this comment - he has no idea what he's on about
@@willtheoct give an example of where this dude showed that he has no idea what hes talking about
@@heikkipalola6760 Linked comment with timestamps: &lc=UgxElWUm4kcoxqzrp014AaABAg
When I was still working with XNA when XNA was still a thing, I made a (successful) attempt at a 2d tiled game prototype with several hundred thousand tiles. I simply made a single array with all the tiles and only rendered the tiles within my cameras bounds + a bit of padding and it worked great. For something like Terraria you definitely don't need huge amounts of optimization to get it to run well on modern hardware. Although through implementations of simple things like chunks, a huge amount of optimization cold have been obtained.
Terraria's developers made the game and only optimized where they NEEDED to. Which is the correct way of optimizing as early optimization can introduce painful and difficult to track bugs.
Why do awesome channels like these always die after promising to make a video about a really interresting topic?
Find a different channel - he doesn't know what he's talking about
William Weissman in regards to making 2D tile games look tough to crunch, yes. it's the same simple logic that's been used since the likes of Mario. (1985 on NES) the only difference today is we can render much more polys on screen. the size of the world means nothing. they could generate an infinite world if they wanted. it's just data. it's not all loaded at once. lol like minecraft. which blows terraria's size away. and the total polys is much higher. "omg, how is minecraft not breaking the computer?! aaargh" **tries setting infinite render distance** bwahaha xD
only a fool wouldn't recognize how stupid that is. and he literally mentions frustum culling. lol frustum culling doesn't come in at all for a grid of cells. that's just knowing your render region. lol you have direct access to what portion is in bound. (xz chunks / xy tiles)
where frustum culling actually comes in, is when you don't directly have a way to just render what's visible. like with 3d polys. you literally have to check if it's inside the frustum. and the only way to do that is check a single point is within all the frustum planes. since doing that for the tons of poly's there are (especially with todays graphics) would be expensive, we just check a larger area that encapsulates all those poly's. meaning some couldn't be culled away. so some off screen poly's will be processed, and simply clipped away.
and again about the poly count, a screen filled with tiles is nothing astounding. literally, the more there are, the smaller the polys are. lol example. say we made them 1x1. omg! 1920*1080 tiles?! how we gonna do that!? that sounds like too many pixels to me! xD
while in 3D tons of these polys will be overlapping, so processing much more pixels. and they all need perspective correct interpolations for each pixel's attributes. and they all need translating/projecting with a 4x4 matrix. (16 multiplications 14 additions 4 assignments per vertex) whereas all 2D tiles need is basic xy shifting. (2 additions 2 assignments per vertex)
basically, he should've done a video about minecraft. lol
Overburdening. Biting off more than one can chew. Getting too ambitious... Setting goals too high. Over-stretching / over-expanding.
@@DlcEnergy Except just because something you render is small doesn't mean it's not a performance hit. A major factor in rendering performance is draw calls, the actual pixel and blend operations you are talking about aren't usually that bad, depending on the complexity of the shader, even if you have a lot of overdraw.
2D games also need to be projected with a matrix, since clip space is 3D even for 2D games, only difference is you have 4 less vertices per object to multiply with the matrix. The actual performance difference between rendering a sprite and a cube is insignificant.
All it comes down to in the end is how many objects you are trying to render. Instancing can play a huge part in reducing performance if you have a lot of similar objects.
Lym my point was that a larger count doesn't linearly increase how many calculations are needed. have you ever had so many 3d polys in the same location and wondered why they're so laggy (when up close) yet fine when spread out? (far away) because they're no longer tiny. translating them all is no big deal. the rendering has a much bigger affect. and for tiles (which we're talking about) is simply 2 additions. you don't need a matrix. we're not even rotating them. lol
you're thinking of how the fixed pipeline of opengl makes you use its builtin matrices to project/translate. stop that. lol opengl is prioritized for 3d graphics. which is why we have the homogeneous coordinates. we can't project before clipping. (since it could divide by 0 or invert projection) we can't interpolate in 2d and expect 3d perspective. if all this trouble is powerful enough for 3d graphics, it'll be powerful enough for 2d anyway. and most modern 2d games would likely make use of most of it anyway. if they're gonna have rotation, they're gonna need tri's to do the rendering.
but again, we're just talking about a simple tile game. do you think mario on the nes would've used matrices for some tiles? and translated 4 vertices for a square? and interpolated over 2 triangles to calculate the pixel? lol think efficiently. and ask yourself how you might do that. test your ideas and see your results.
there's PBO's. there's glBlitFramebuffer. you can just upload the raw pixels to the buffer. and whala. no calculating over tons of interpolated texture coordinates for tons of triangles for no reason.
and if you wanted some shader affects, you could just render the texture. of course if maybe you wanted wavy grass or something, then you'd render them separately.
and if you didn't want to keep re-rendering all the individual tiles over and over, you could chunk it up. have a range of tilemaps. so as you explore more tilemaps are built quickly. and those larger pixel streams can be uploaded quicker. anytime a tile is changed, its tilemap is updated.
yada yada yada...
I’m sure it would work the same as Minecraft where the game only loads up what’s in the screen and doesn’t load the other info until you turn around. That’s before actually watching this.
Keep it up! You'll have loads of subscribers in no time with videos like these!
;-;
:[
:$
well...he didn’t keep it up. :(
Hyped for that procgen video!
Subbed and belled. This is great stuff. I really hope you're able to do a full return!
The world of terraria isn't infinite, I feel the credibility of the rest of the information is lost. This is a simple fact about the game's world and any research into it would reaveal that.
Theoretically infinite, not actually infintie. By changing the parameters of the world generation you can make it as large as you want (within the limtis of your computer) and not simply a scaled version.
Fixing the map to a predefined size is one way to avoid that issue of so many tiles.
This just popped up in my feed and I loved it! Was genuinely interesting and informative!
This video was my first introduction to your channel and I thought from reading the title that Terraria used some cool bitwise pipeline to optimise the tile rendering :/
Really liked all the points you raised, and you explained them super well. The tree analogy was awesome.
As someone that got into codding some, and loves game development, I would have had a totally different approach to it:
First, instead of having tiles perform actions every frame, I would have entities perform actions. So the tiles would be stored in a arrays, one for each chunk, and entities would be handled separately.
The blocks would have properties and methods, like HP, but they don't update on their on so they are not iterated through. Then I would have a an entity list, that is iterated through periodically, which contains things like trees, enemies, etc... And those would be capable on calling on methods periodically. Though I might have different update methods getting called whether they are in a visible chunk or not, and then just have the engine go through a list of lists of entities per chunk calling either "light update" or "heavy update".
I really needed something like this for my games because I have always loved 2d survival rpg games like Terraria or Zelda
you can straight up ignore the part about frustum culling- that's only for 3d games.
For most 2d games you don't actually need tricks to save on performance. I'd recommend ignoring this dude
I love these. Because maybe I wanna build a game. But I want to add an element. These videos give me so many ideas and ways of looking at these problems. These vids are gold. Can't wait to see more.
I just saw this video is years old, but I wanted to point out that I'm pretty sure Terraria's NPCs also load several chunks around them as they can be killed when you're not around them
terraria doesn't use chunks. at all.
Only came across this Chanel yesterday and wtf, it's great. I hope you get back on these.
I'm loving this channel now. So interesting :D
And I love how you wrote when the next video is coming out on the header picture of your channel XD
You didnt mention sprite batching, which is really the main way they optimize their tile rendering because in modern opengl, drawing something to the frame buffer, isnt the same as rendering it to the screen. You can combine all the tiles into one big model and succesfully render all the tiles in one draw call
I love your work man, Thanks for Coming back.
Here are few more things we do to optimize these type of games.
Using Atlas is very crucial so we don't have to change texture.
An array of Similar tiles is combined into 1 tile, with bigger size and multiplied UV.
Static Mesh of Multiple Tiles are combines into One mesh, to hugely reduction in draw calls.
Hey, I don't know if you will even read this, given your inactivity, but I'm still really grateful for your clear explanation of this topic. I'm really inexperienced when it comes to programming of any kind but find this stuff quite fascinating!
It's a shame you didn't follow up with the Procedual Generation part though, as others would agree.
Hope you'll come around to do some some day. I'll just leave a sub for now. :)
EDIT: Maybe if you still have a script for that video you could also just release that on it's own. I think it would help a lot of people understand the technical part!
... pleeeeaaaaseee? :)
"grateful for your clear explanation of this topic"
the guy didn't explain this properly at all, threw in concepts and comparisons that don't make sense, and just... don't listen to him. He doesn't understand what he's talking about.
There are further optimizations. They're a little complex to explain just by typing here, but I'll do my best:
1. Don't check every chunk of tiles. Instead, keep track of all interactive objects (player, enemies, trees) and their position, that is, the index/id of the chunk they're currently on. So, for example, if player is on chunk 3, you know that you only need to update this chunk and can ignore the others
2. The second optimization is called dirty rectangles. It takes advantage of the ghost effect caused when you don't clear the screen. Basically, you draw all tiles once and then you never clear the screen again. After that you only draw the tiles that changed on top of the old ones. The tiles that didn't change will remain there since you didn't clear the screen. The only problem with this technique is when you need to scroll the screen, and this leads to optimization 3
3. If your graphics card has enough memory (this is the case nowadays), instead of drawing the tiles directly on the screen, you create a large image on the GPU memory with the size of your whole scenario. Then you draw all the tiles in this off screen image once, and every time the game updates you draw the updated tiles on this image. Finally you make one single call to the GPU to draw this image on screen. Since the off screen image is larger, you can only draw a portion of the image on the screen (operation known as blit). By chosing a different portion of the image each time, you create a virtual scroll effect. Also this technique improve performance because the GPU is much more efficient on drawing a single large image than drawing many small images. However, with procedural generated scenarios like Terraria, it's not possible to fit all the scenario in a single off screen image. This leads to optimization 4
4. Instead of drawing a single huge off screen image, which can actually degrade performance if the size of the scenario is too large, you can subdivide the scenario in several images/sections. So, if you have a viewport with 1920px width, you can create an off screen image with 5760px width. If you center this image on screen, you will have 1920px displayed, plus 1920px hidden to the left and 1920px hidden to the right. This way, you can scroll the screen for both sides with very little impact on performance because that part of the scenario is ready, you just need to show it on the screen . Now, suppose that the player starts walking to the right, after he walks 2880px, it will be in the right edge of the scenario. This is the moment when you can generate the next section of the scenario and draw it to another off screen image with 5760px. So, if the player walks to pixel 2881, you stop showing the previous off screen image and start showing the one you just created. Repeat the process ifinitely
5. This final optimization is not related to drawing things on screen, but is related to the way you update the game state. Generally you create objects on your game, update them, draw them on screen and once finished you destroy them to free memory space. Now, this technique is called object pool and consists of keeping your objects on memory instead of destroying them. So, suppose you have an enemy that comes from the right of the screen to the left, like the goompas on super Mario. You create the enemy, set it's position to the right edge of the screen and on each frame you move it some pixels to the left. When the enemy passes the left edge of the screen, instead of destroying it, will just reset it's position to the right edge of the screen. On the player's perspective it seems a new enemy, but it's just the old one. You can change, it's position, speed, sprite and many other properties to make it seem a completely different enemy. The secret here is that creating new objects is much more expensive for the CPU then changing the existing ones. For a few objects you may not see difference, but for hundreds or thousands of objects this can have a huge impact
What about corruption recursively converting tiles to more corruption tiles, which themselves are creating more corrupting tiles, exponentially.
@Badog98 I didn't say it increases speed with more tiles. I only really said that the method shown in the video doesn't explain real Terraria's behavior.
@Badog98 Nothing really new to me, but I think it's clear.
You are welcome to come back any time! I loved the video and i would love to see more
As a game developer I love these videos! It's like mental candy! Keep it up man :)
Great video. There are plenty of similar videos catering to us seasoned devs, but I love how you took the subject and made it accessible to the average gamer who may not have any programming background.
Why do people always say "fry" your computer. Computers only "fry" under very specific circumstances, and playing a demanding game is definitely not one
Why do people say downing in money? It's impossible to drown in paper. Because it's a saying, somthing that just developed over time, people don't actually mean it fried their computer, it's just another way of saying the computer shat itself
Plexy_ Glass no. Frying a computer mean it’s won’t work anymore, like if you shock your motherboard. Playing a demanding game will crash your software or your computer but it won’t be fried/bricked.
@@plexyglass429 because it has a very specific meaning, a short circuit is an actual example of "frying" a computer
@@snoopy7156 you could likely destroy your computer by running a demanding game, GPUs and other computer parts can burnout from overuse or working them too hard.
@@thedarklordx Did you ever see a computer since 1990? Every component in the system since the 2000s will protect itself and shutdown if overheated.
I like how when you needed something to be happening in the background while you spoke you decided that killing a crimera with a bronze pickaxe was the content you needed
This video talked about Terraria, but it was actually describing Minecraft.
I watched 1 video, Subscribed, then was very dismayed to se that the last upload was 2 years ago
Just found your channel, what a shame you haven't been active in so long
Wish he comes back
maybe he is dead
@@gibran.zidane i wish his not
Hilarious how the UA-cam algorithm sends me a pretty high quality video, then I go to subscribe to the channel, only to find out it's been inactive for two years. Then I go into the comments to find out that the recent recommendations have inspired the estranged creator to continue his work. It's a pretty uplifting story actually and it makes me excited to see more of your content in the future : )
First: I never questioned it cause computers are big ass machines doing trillions of calculations per second.
Second: My computer can't run terraria at 60 fps.
same.....rip
Found this video in my recommended tab. Subscribed. Went looking for the next episode. Surprise surprise.
"13 fps is unplayable"
Meet my computer
Very nice explanation of basic CG concepts. This must have been a ton of work with all the little examples. Keep up the good work!
@JamBixX Well I know that Terraria does it differently but still he explains some basic concepts quite well
@JamBixX Well then be more specific... where is he wrong?
@JamBixX Yeah? And? Has nothing to do with basic Game Development Patterns...
@JamBixX Do you actually know anything about Game Design or are you just salty because he didnt play Terarria?
Spoiler Alert: Terraria isnt what this Video was primarily about.
So either start being constructive or GTFO
"procedural generation"
Ahh yes, making a video about a something you haven't checked.
"How doesn't terraria fry your Computer and Crash?"
How? It frys my computer and crashes
2 years later:
Me: 🤔
UA-cam : SO YOU WANNA SEE A BOII WHO EXPLAIN TILES YES ?
Great video! I study programming so this was actually very informative and I learned quite a bit from it. Thank you very much!
Lmfao
answer:
the same reason Minecraft does not crash
that's right!
friendship!
youtube just recommended this. while you say this is inaccurate and appreciated I really enjoyed this video man!
i mean, some quick math and you see that even on the biggest map size, assuming each tile is a byte, that'd only be 20mb of data, which really isnt that much
and yeah, even with some more data per block, you wouldnt exactly hit the modern ram limit of 8gb.. or even 1gb
and rendering.. thats way way simplier, just render whats on the screen...calculate which tile is on the top left corner, and the bottom right corner, do a nested loop and draw, also some other math to offset the player position by the blocks to add 0-16 pixels
I did not understand a single word of that
@@alyx8815 well, basically.. lets say that terraria only had (a maximum of) 255 diffrent block types, for example
dirt = 1
stone = 2
wood = 3
that means we could represent each tile/block with 1 byte (since a byte can store a number that ranges from 0 to 255)
now, the biggest terraria map ( terraria.fandom.com/wiki/World_Size ) is
8400 tiles wide and 2400 high, multiply those togheter and we get how many tiles/blocks are in a whole large map
20'160'000 blocks, and if you give 1 byte to each block, thats 20 mb, so it would take 20 mb's of ram to story that much information
now terraria problably stores other information for each block too, so you might need to multiple the ram usage a few times, but even still, its not that much ram for a modern computer
and regarding rendering, well.. you can calculate which blocks are gonna be inside the screen by figuring out.. well, which blocks should be in the corners of the screen (depending on camera and player position and zoom) and then just draw all tiles in between
not sure if this explanation was better or worse than my original comment but yeah ^^
@@EnderCrypt Thanks, this was a huge help! Memory was the first question on my mind when he started talking about storing data for that many tiles, which he didn't clarify in the video.
This and the Portal video were awesome. Hope you keep making content!
And so, part 2 never came
I just subscribed today in 2019! I'm an aspiring game dev and this is exactly the kind of stuff I love watching. hope this series continues someday.
Watch someone who actually knows what they're talking about.
And you can also only calculate tiles that touche air.
Glad I stumbled upon this right when you are thinking about posting more content, you earned a sub!
i mean if you can render a bunch of polygons to make triple a realistic games, of course you can render tiles.
Yeah so UA-cam just randomly started to recommend multiple of your videos on my feed. I don’t regret clicking :)
I’m majoring in cs and Terraria is my fav game. This vid just put two together which is awesome
1. Terraria might not have pixel perfect design, so just because I tile is drawn in 16px doesn’t mean it takes 16px on your screen. It might take more which means less tiles to draw = less work.
2. Drawing 8,000 sprites at 60 FPS is no problem at all. Computers today can perform over a billion operations per second. Billion / (8000 * 60) = ~2000. A computer can definitely draw a single sprite in 2,000 operations. Of course, there are other things happening, but a billion operations per second is on the low side. But this graphics stuff is usually done through parallel processing with dedicated hardware meaning each sprite can be drawn at the same time, taking less processor time overall.
3. 2:50, so you’re assuming that in terraria each tile has its own functionality and you put that in the draw call for some reason. I think it’s reasonable to say that the tiles in terraria are mostly static. Dirt does not need it’s own functionality until the player interacts with it. There are some elements which do have their own functionality, like growing plants, but that doesn’t mean that each is an object, running a timer until a random time when they grow. More likely, the game selects a couple tiles per frame at random. Eventually the plant tile will be selected in random time. This is how Minecraft works.
We still wating for you, sir
This video is not complete. You see, sure, the "store timer" trick works for trees and crops, but doesn't work for corruption because corruption SPREADS. So corruption blocks HAVE to be enabled every X ticks even when they are off screen so it can properly simulate the corruption growth. The timer trick would only work if the growth is completely deterministic.
Seems like you haven't played much of Terraria, because most of what you say is false and doesn't refer to the actual behaviour of Terraria's game engine whatsoever.
CHUNKS!!1!
One of the fist things that I try to create once a start to learn programing was make a terraria clone,and boy did a learn fast, realy fast that you cant just create a shit tons o tiles and expect to not have a 0 fps game on hand hahaha,and my approach to procedural was nothing but give a randon(-3,3)*16 to the Y coordinate of the fist tile,than fill all tile below,no caves,nothing,just a mass of tiles running at 1 fps hahahaha,I did improve a lot now that I think about it :D,amazing video,sad that the channel dont post any more =/
and now imagine 3d world "tiles" which are pixels of textures of 3d objects which are basicly 2048px each and can be repetable on 1920x1080 resolution.
and now imagine 4d.
You can only see the outside-faces of 3D blocks. Also no, i can't imagine 4D very well xD
Using chunks is huge in mc
Great channel! Come on back and keep making videos. I would pay for this type of content.
why so many people just finding this channel now?? (i'm one of them)
Up Next: How does Minecraft handle *trillions⁴* of cubes without turning your computer into another Tsar Bomba?
Clever, I always wondered this.
Simple and fun tricks that everyone should use. Now there's more too I can think of such as how to store those tiles (2d array or list by column)
> 13 fps
>"this is unplayable"
Found the wealthy gamer
yeah! when I get 13 fps, I think "wow! this game is running smoothly today! :D "
XD
Idk where that 8 bit music at the end come from but it made me happy.
I’m going to assume this guy died, or an event in his life occurred that hindered his ability to make/upload videos.
Scourgi he realised that the map in terraria is not procedurally generated
Or he simply quit.
No he is still here he recently commented this video
And most important: Terraria doesn't use Unity3D which is quite slow (I've heard the new ECS is faster). A few years ago I compared rendering a lot of sprites. While pixi.js (a JavaScript Rendering Framework) handled 30k Sprites and libgdx handled over 50k, Unity3D FPS dropped below 25 with just around 5000.
Misleading, wrong, misleading, wrong
Who is asking this question? There's not 1000s of tiles on screen all the time, they could all share the same texture and many of the tiles are repeated (instanced), the geometry is the same and with it being tile based positions are highly predictable and easy to compute. It's not like the game is renderimg multiple complex 3D models with high Res textures and tons of particle effects, AA post processing and other complex effects. The GPU is massively parallel so rendering a couple thousand small tiles mostly all in sequential order (certainly all in a grid) with the same geometry and potentially using the same texture really isn't a very impressive feat. I've managed similar performance (without other fancy effects) without any batching as I was using SDL to render which did individual draw calls. Your graphics card may even have a CUDA core for each tile on screen at lower resolution so 60fps would be easy to achieve.
Game devs are asking this question and if you aren't, maybe you're missing something. Rendering the tiles isn't the hard part, it's actually handling all the tile data of every tile in the world at the same time in real time. A large Terraria world is 8400 x 2400 and contains 20160000 tiles that need to be handled. Data that needs to be handled includes tile type, id, position, collision,, as well as other things that update real time such as growth for plants such as blinkroot or moonglow, grass growth, vine growth, corruption, crimson or hallow growth, chlorophite growth, etc. Terraria needs to be able to calculate all this at the same time. What the video mentioned about the tiles saving the time last on screen is still not true, as proven because we can see that grass has grown further out on a dirt plane, which is impossible for the time method because the tiles further out would not be able to update because the tile with the time data has not been loaded in yet. This theory was disputed by an ex-Terraria developer on the Reddit post for this video. Keep in mind that Terraria is very capable of running at 60fps on low-end machines that may only run on integrated graphics and with only two cores for CPU, and that Terraria was first released all the way back in 2011, when computers were definitely not as powerful. Here's a link to the Reddit post, and Solsund is the developer who worked a bit on Terraria. www.reddit.com/r/Terraria/comments/63b7h4/how_does_terraria_handle_thousands_of_tiles/
@@ramennnoodle Chunk based is nothing new and based on things I've done in the past I'm still not overly impressed however I've never ran terraria on really low spec hardware however I've run 3D demoes on very low spec hardware rendering 1000s of triangles at high frame rates. I don't see any issue with the method mentioned in the video for updating.
@@ramennnoodle lastOnScreen as a value could be zero initialised for each tile.
@@ramennnoodle I'd say also that if these Devs are really struggling to get their games to come close to this performance then they are missing something be it rendering techniques or perhaps the issue is more to do with data locality and making their map formats a bit more cache friendly. Games are hard to make efficiently but there are many known techniques and optimisations available if people are willing to research. I've certainly had terraria lag a small amount when playing multiplayer on a fully wired LAN so there was no connection issues and only 2 players.
3:53 The answer to the question
Oh I wish I had found this channel earlier! Please, bring it back from abandonment, this is a fantastic learning channel.
You're using Unity, that's your first mistake.
I'm pretty sure Unity can handle it with good optimization. But I see your point. It has a pretty large overhead as it is. Very simple shaders can help, going with forward rendering path or even vertex lighting also does a good job. Generating chunks, storing them as images, and regenerating them on runtime also does a good job. Long list of optimization and simplification.