Terraria wiki: "Small - 4300 blocks wide and 1200 blocks high, sky limit about 360-370 blocks above underground level." Oh, and you also need to save and load it, which, depending on how you do it, could take a lot longer than generating the world.
And obviously Terraria would do it faster than BYOND would. I've never used a language slower than DM before.
DM isnt just slow
BYOND is absolutely terrible at removing, creating or moving objects If you had 10 projectiles moving down a corridor 1 tile per tick it will lag the server to death Most of SS13's atmospheric system lag was due to a badly placed del And one of the biggest performance hogs in SS13 is currently the spark and smoke effects due to how many objects they make and have moving | |
del() is slow on itself. It has to remove all references. It's better to set loc to null and let it die.
| |
Zaoshi wrote:
del() is slow on itself. It has to remove all references. It's better to set loc to null and let it die. The problem is that if anything is still referencing it, it never will die. leaving the object in limbo and piling up more and more on the server over time. If it's for projectiles and such then it's fine to set loc to null, but it most cases it just makes things slowly worse. | |
Bravo1 wrote:
Zaoshi wrote: This is where proper management of references comes into play. Sure, if you let a bunch of things retain references to stuff after its no longer useful, then yes. But as Zaoshi says, the (effecient) way to go about it, is to null out references and let the GC take care of it when it feels like it. Anywhere you explicitly del() something, you should be doing so for a good reason. | |
Bravo1 wrote:
Zaoshi wrote: That's wrong wrong and again wrong. If you delete something that has reference you have bad design and potentially create runtime errors. | |
Zaoshi wrote:
Bravo1 wrote: Not true, if you know the reference will never be used again then you can safely call delete. Unless you don't know what's going on in your code del() is safe to use. I don't know about you, but when I code something I make sure I know what that code does and when. Maybe I'm STRANGE. | |
There's is no del() in Java or C#, with no del() you'd run out of memory, that's why you have bad design. I think del() should be removed in BYOND as well to force better programming design.
| |
There's is no del() in Java or C#, with no del() you'd run out of memory, that's why you have bad design. I think del() should be removed in BYOND as well to force better programming design. ...As someone whose native language is Java, and who works in C# regularly... This is the most confused sentence I've ever read on either. | |
Tobba wrote:
DM isnt just slow You can get around that by using object pools like you would in any other sensible language. | |
Ter13 wrote:
Tobba wrote: It depends on how it's being used, honestly. Object pooling can be trivial if you don't know what you're doing; instead of saving resources(which is what you're trying to do), you will only be augmenting memory, and I can only imagine this will be the case for some of the programmers here since most of them don't have experience doing it. | |
Magnum2k wrote:
Ter13 wrote: A good example from SS13 are rigged powercells, whenever anything draws power from them they explode and remove themselves, nulling out any references to them, and any code that uses them checks if they're actually there before using them (and it will in all cases just act like if someone removed it manually), theres also really no good way to do it other than this that isnt extremely ugly | |
Zaoshi wrote:
There's is no del() in Java or C#, with no del() you'd run out of memory, that's why you have bad design. I think del() should be removed in BYOND as well to force better programming design. We're talking about DM not C# or Java. If I was using a different language I'd obviously follow different rules. Just because you can't manage your code properly doesn't mean del() shouldn't be used. I use it all the time and I rarely have issue with it, so you must be doing something wrong. It's the same argument as having "usr" in procs. If you know exactly what the proc is doing, how it's called, and when it's called then you should be able to tell whether or not it's safe to use "usr". If you can't then you're not very good with DM, simple as that. | |
If language supports one or other feature it doesn't mean it's alright to use it.
For example: var/obj/O = new Both, obj and mob contain loc variable and DM/DS won't throw any error. Should you do that? No. | |
You're right about that, but your comparison is terrible.
No one who knows that they are doing would ever change over type like that. It's stupid. I can see why setting loc to null is good and I'm not saying you should use del() over it. Personally though, I don't code my games to the point where del() usage is an issue. Telling me "you're doing it wrong" when it's entirely an issue of personal preference makes you sound controlling. I never have issues with del() and I'm using it what it was designed for so what's the issue in using it? Just because you don't like black cars because they heat up in the sun doesn't mean people shouldn't buy black cars. Get over it. | |
Sort of like the "go to" thing.
People swear it should never be used under any circumstance, simply because a while back tons of people were using it haphazardly. | |
Dariuc wrote:
Sort of like the "go to" thing. The way in which your software solves/approaches a problem should reflect the method that best fits the situation. There are almost always multiple ways to get somewhere, and many considerations to decide whether something is 'the right way'. You may look at how robust the code is (goto and the : operator fall under the category of code that usually won't be robust), how effecient the code is (Letting the garbage collector decide when to GC is usually more effecient than forcing its hand with del), how easy it is to extend (Use of overridable procedures and datums), and so on. The art of figuring out when to do one thing and when to do another, is a part of programming. And its one that we can all vehemently disagree on, until the end of time. So why not save us all some time and sanity, and take the disagreement (Which by now is basically 'No do X THIS way, you're stupid) to Chatters or the pager? :) | |
Alathon wrote:
Dariuc wrote: This, PLEASE. | |
When you analyze BYOND one feature at a time you can ignore lots of problems. Code organization, design, and performance don't matter when you're writing 50 lines of code to implement a single feature. You're less likely to have bugs because you don't have other features that can interact and interfere with each other. You don't need to do as much testing. Implementing each individual feature sounds easy (for most of them, at least) because that is the easy part. These kinds of software projects are difficult just because of the magnitude of the project, not because of the complexity of individual features. This is the reason why most BYOND games aren't completed - people are often capable of implementing any feature the game would have but can't handle those other problems (organization, design, etc.) that creep in as the project gets larger. If you think a project is easy because every feature is easy, you don't understand how software development works.
Bravo1 wrote: Terraria could be replicated in BYOND if it weren't for the fact that you can't display that many tiles without extreme slowdown from Dreamseeker. Even at somewhere around 15x15 there's noticeable lag. Since each block seems to be it's own entity then you're looking at easily 5-10 times the "tiles" on screen. I doubt that BYOND would handle drawing so many tiles (many having transparent overlays to show illumination) and it certainly wouldn't handle the particle effects. The illumination would be difficult too since the tiles are smaller and there are so many more that would need to be updated. Kaiochao wrote: I want to know, what kind of popular game is BYOND even capable of making? Just building games and NES-style RPGs? I figure you could re-make almost any NES game using BYOND. On one hand that's a good thing because there are lots of fun NES games. On the other hand, it's only possible because NES games lacked the graphical effects that BYOND can't really handle. I wonder if anyone realizes; if BYOND were to implement Forum_account's 3D idea (not 3D models, but simple boxes with icons slapped on the faces), even a Minecraft clone without mouse-look or dynamic lighting made with BYOND would not be hard to make at all. You might not be able to have lighting that's exactly like Minecraft but you could have built-in dynamic lighting easily enough. BYOND is still missing something. It's not that flexible, fast, portable, or easy to use. Using BYOND will always be a tradeoff but it's not quite good enough at any of those things that you can overlook problems with the others. Right now people say things like "DM is slow" and there's no way to avoid that entirely - there will always be something about BYOND that's less than ideal. Adding a big feature (better graphical capabilities would probably be the easiest to add) would let people say "DM is slow *but* I can make a 3D game, zoom the camera in, rotate the map, scale/rotate objects, and have dynamic lighting." Providing frameworks would be another easy option. The best people can say right now is "DM is slow but I couldn't figure out Java." | |
You'd also have to generate tiles in groups of 4/16 to account for the sub-tiles.
It also depends on the size of the world.
Of course, you're right that it'll be slow, but it'd probably takes ten minutes rather than hours to generate a decent map.
(though terraria does it in less than 60 seconds)