May 17 2009, 9:06 am
In response to AJX
|
|
Stephen001
  |
The irony being that you could've implemented this and done any relevant artwork in the time it's taken to discuss it.
|
Stephen001 wrote:
The irony being that you could've implemented this and done any relevant artwork in the time it's taken to discuss it. Yea, probably. But I've only spent less than a minute on any given post I've made here. For others though, perhaps. | |
Slime Lord wrote:
The resources aren't that big and it shouldn't take anywhere near 2 hours. Hell, I'd bet it would take less than 15 minutes to make.Response: AJX wrote: Anyway, doing it sloppily would be fast and easy, but doing it right wouldn't. And even though the programming would take anywhere from 15 minutes to a few hours (depending on how many bugs you encountered) it would still cost resources (depending on what way you implemented it) My Speculation: The way that most low level programmers would implement this would be very very resource inefficient. Judging by the code you wrote up in an argument against me, I'd say my speculation is right on. There's two types of programmers: those that put forth the effort to create something good, and the lazy ones. Sadly with your posts in this thread it seems you fall in the latter category.There are actually more than two types of programmers. And if you were to ask a professional programmer I guarantee you that they would not spend time working on something that would only offer a very slight aesthetic improvement WHILE costing resources, Even if it wasn't a massive amount of resources. I can't say how many different categories of programmers there are, but I don't think that measuring cost and result would fall into the lazy category. Considering that decisions like that must me made constantly in life, it would seem logical you would apply them to programming as well. Even if it did take longer to program it, it's still something that adds polish. Let's say it would take an hour, why not take an hour out of your time for some aesthetic appeal to your players?Actually I'd speculate to program this properly for a low level programmer (most of the people in this discussion) would probably take more than a few hours to work out the problems and would still be inefficient. Again, this would not be that big of a resource hog. I doubt it would even be noticable.You're provably wrong. (See next line) No guarantee that everything (or anything) in there is good programming practice. That's the effect I believe you were looking for.In fact you're right, I don't find this to be good programming practice. I also find it to be very very inefficient... [edit] Here, I even whipped up a quick example. http://www.byond.com/members/SlimeLord/files/tree_src.zipI'll write up another post on how this runs in a more heavy situation in a minute. **** EDIT: Jesus... First off: Slime Lord wrote: That seems to run fine on an Intel Atom processor with integrated graphics. I guess there may be a problem if you have over 10000 trees, I'll whip together the other one and see how it works.I have an AMD Athlon 64 X2 3800 (2.01 GHZ) and that causes my computer to completely lock up. I don't know what the hell kind of atom you're running, but DIRECTLY copying and pasting your code (with the world/new() part as well) causes a full 50 CPU constantly and I can barely move. "There are two types of people who make posts on forums: The ones that don't read posts before responding to and arguing with them, and the ones who actually take their time to come up with a coherant response. Sadly with your posts in the thread and the code you supplied it seems you fall into the former category. " AJX wrote: The Naked Ninja wrote: What you programmed creates the exact same problem as using see_invisible would. Why would you circumvent using see_invis if you're only going to recreate the problem that you're trying to avoid? Furthermore after all the times I brought up resources being an issue, and you responding with "no they aren't", I find it humorous that the example you created was a very inefficient way to do it... Most games ave a very large number of trees, which requires you to take a very efficient approach to this matter. And even if there was only two trees that isn't an excuse to exercise terrible programming practices. Even if you aren't going to reach the resource limit because you don't have that many trees or you are hosting on a super computer you still shouldn't purposely write inefficient code... I'm not quite sure what you've been trying to prove, but everything you supplied here seems to prove yourself wrong. I already mentioned the way you could program this that would actually work, but it would require a bit of fine tuning and intelligence on behalf of the programmer, and the ultimate result would not be that great. | |
You can use somebody's example posted earlier, which could be made as quickly as mine was. He responded soon after me -- his would probably be easier than mine to create (and take up less lines even!). Go for it, just stop complaining. Create stuff in your game that your players would enjoy to see, don't be lazy. Do you think every title by Blizzard is widely enjoyed because they cut corners? Blizzard throws a game out if it doesn't meet their high quality standards.
| |
I understand your concern behind it, but either way the situation wouldn't be too difficult to handle with images.
And what's the concern of the size of your resources increasing a little, if it provides a decent feature to your game? | |
The Naked Ninja wrote:
I understand your concern behind it, but either way the situation wouldn't be too difficult to handle with images.Not too difficult, no. But unless it was handled properly then it would be a strain on resources. And what's the concern of the size of your resources increasing a little, if it provides a decent feature to your game?Paying lag for tree transparency isn't a wise trade-off in my opinion. The example given by the Slime Lord caused a great deal of lag. That is a massive resource hog for a minor visual effect. | |
Slime Lord wrote:
You can use somebody's example posted earlier, which could be made as quickly as mine was. He responded soon after me -- his would probably be easier than mine to create (and take up less lines even!). Go for it, just stop complaining. Create stuff in your game that your players would enjoy to see, don't be lazy. Do you think every title by Blizzard is widely enjoyed because they cut corners? Blizzard throws a game out if it doesn't meet their high quality standards. LoL... Laziness isn't the issue here. Again, please read posts before you respond to them. And how am I complaining? Because I offer a point of view that contradicts your own I am complaining? Anyway... I'm sorry you don't like that I disagree with you. And I'm sorry you are unable to respond to anything I said in that post. But if you aren't going to respond with something of value other than an unsupported argument, why bother? BTW: If Blizzard was working on WoW and saw that they could add a special kind of reflective fog to the game at the cost of 4% processor load on all of their servers, do you think they would do it? I mean by your logic, come on... It's just resources... they aren't limited or anything... I mean, not coding it even though it would only add a very minor visual effect would be cutting corners, right? Think about what you're saying here... People make decisions on a very simple premise: Is it worth it? Try applying logic here. EDIT: Ok, this is getting a bit ridiculous. As Stephen already said, the code for this functionality could have been programmed (i mean programmed CORRECTLY) in the time we've spent arguing semantics. If anyone here can make a code that provides the appropriate functionality then I encourage you to do so. If not in the next 3 days I'll write it up, I just simply don't have the spare time right now. | |
The days of resource download lag are over. You can now successfully link your resource download from alternative locations without having it bog your world down. The only way this would be a problem would be if you were generating the graphics for it at run time.
Then again, it all depends on how competent of a programmer you are. | |
I think that there is a terminology misunderstanding here.
AJX is talking about CPU/RAM/HDD/bandwith as resources, which are all four limited for a server, while you are talking about downloading the game's resource file. Please note that the problem at hand would have little influence on the game's resource file, but might drain considerable resources, depending on implementation. | |
Schnitzelnagler wrote:
I think that there is a terminology misunderstanding here. Thank you very much for the clarification. And yes, you are very correct. I didn't think anyone could think I meant the size of the resource file... :/ But yea, situation clarified. -.-' | |
Well I've noticed the size of the resource file, when downloaded from the server, generates more lag than anything else (aside from poorly programmed loops)
I didn't think that resources in the game (once downloaded by the client) generated much CPU, unless of course they're programmed to contain a bit of calculations. But I suppose I could be wrong, anyone mind clarifying this properly? | |
The Naked Ninja wrote:
Well I've noticed the size of the resource file, when downloaded from the server, generates more lag than anything else (aside from poorly programmed loops) The size of the resource file is influenced MOSTLY by icons included at compile time, and modified versions of those icons that are created at runtime. If you have an image that is one icon, then you make 100000 more of those images with the same icon, it has 0 influence on the resource file size. I didn't think that resources in the game (once downloaded by the client) generated much CPU, unless of course they're programmed to contain a bit of calculations.File size of the resources or how many bajillions of pre-included icons will not cause lag in and of themselves. Doing things with those icons *CAN*. Example: What we're discussing here. Adding an image to every single tree in the world. That can very quickly add up in resources. Especially if you code it like Slime did and have the entire list of images added/removed from your view constantly. But I suppose I could be wrong, anyone mind clarifying this properly? Basically it works like this: Having the icons in your game will increase only your resource file. What we're discussing here, which is dynamically changing tree's appearances by moving large lists around (and he implemented it with some seriously heavy inefficient coding) causes both (CPU) lag and memory usage. (Adding an image to every tree in the world when you have 10k trees will affect your memory. No idea how much, but all I can say is it will. | |
AJX wrote:
EDIT: Ok, this is getting a bit ridiculous. As Stephen already said, the code for this functionality could have been programmed (i mean programmed CORRECTLY) in the time we've spent arguing semantics. http://www.byond.com/members/AJX/files/Libraries/ Tree%20Transparancy%20V0.1.zip Newer Version: http://www.byond.com/developer/AJX/TreeTransparency So... a few notes about this: 1: If you fill the entire screen with trees and then run around rampantly you can get your CPU up to a good 10% with only two players. That means that if you had a full screen of trees and 5+ players (and are on a dual core like myself) you'd be lagging out the game. Bear in mind that I said FULL screen, as in every single tile has a tree on it. If you actually make a map like that you are bad and should feel bad, but whatever. (Also that is moving at 1 move per tick, whereas most games have movement slowed) 2: I haven't checked this for any bugs or fine tuned anything. It is only meant as a demonstration... 3: It took me one hour and thirty minutes to write up this code and create the icons (the alpha ones, used BYOND procs, but it still took a few minutes.) And there are still a few glitches that need to be worked out (like mentioned above) 4: I personally don't like this because it uses too much processing power for my tastes. I'm sure there are ways to make it more efficient... I'm lazy, and it doesn't interest me. -.-' 5: You could make it so the entire tree goes transparent instead of just the tile you are on but that would require tagging IDs to the trees as they are created (in case of overlaps) and yea. Again, I don't have the interest. If this demo was going to operate 'appropriately' for how I described, then I would code that. But again... just a demonstration. No idea how that would affect the resources either. 6: Personally I don't use trees like this, I use overlays off the base locations to keep the object usage down. 7: Meh. | |
Again, would it be possible to post the code in dm tags here instead, so that someone can judge it without having to download the whole zip and checking it for infections?
Thank you in advance. | |
Schnitzelnagler wrote:
so that someone can judge it without having to download the whole zip and checking it for infections? I understand your concern, but you really have no good reason to scan such files that are just opened in a text editor for infections. ;) Malware scanning will generally never benefit you in such a situation anyway (even if there was something malicious about the project), so you don't need to bother. But, I'd think that if this concerns you then you normally should have a resident AV automatically checking everything anyway. Well, I also understand it was probably just an excuse for the code to be posted, but the same still applies. =P | |
Schnitzelnagler wrote:
Again, would it be possible to post the code in dm tags here instead, so that someone can judge it without having to download the whole zip and checking it for infections? Well meh, here: Not that this is only one of the two files. This is the one that is most relevant to the functionality described, but doesn't have a few of the things necessary for it to function properly. Here is the hub entry: (Hidden, because this isn't in a "polished" version yet that I would want to release) http://www.byond.com/developer/AJX/TreeTransparency obj/Terrain Note: That edit wasn't necessary. Didn't realize that BYOND automatically prevents you from adding duplicates to your images. :S | |
Edit: Whoops. Forgot to update the file on the HUB entry. Done now. -.-'
AJX wrote: http://www.byond.com/developer/AJX/TreeTransparency 5: You could make it so the entire tree goes transparent instead of just the tile you are on but that would require tagging IDs to the trees as they are created (in case of overlaps) and yea. Done. And fixed my spelling mistake. Haven't thoroughly bug tested, but it appears to work as intended. EDIT: After playing around with this I find it to be a fun little toy to have. I'd like to be able to go back in time and write it more modularly so you could have skills that let you see through trees, etc. Would be fun. I may still do this if it manages to keep my attention long enough. Though I am afraid of how this will react when in a situation with 20+ players. :/ I also haven't tried this over the internet so I don't know how it works with delay. | |
You fail to realize that trade-offs aren't evaluated the same way by everyone.
First off, you would need: - means you spend on this + means you gain 0 means you already have - Time (less of it if your have more experience) 0 A tree icon, which you would probably already add. + A transparent tree which will probably be about than 336 bytes, 12 bytes more than normal, assuming that "normal" excludes the standard full transparency that's been around since BYOND 3.x - Extra Programming + Prettyful-ness + A good strategic element 0 You still have the same FPS if you are effecient. So you used more of your time and a couple of extra bytes to get a small effect. I do that all the time. So do you, even if you don't implement additional features this small. What am I talking about? Bug testing. I know a lot of people that imedieatly exit and go into super debug mode whenever they see a bug. Occasionaly, a bug actually gives you a new game idea. Even the /smallest/ things can lead to big changes. | |