Wow, i am amazed!
This is the best update I have ever witnessed on my 4 ,almost 5 years of playing byond!
For the creators of this, thank you!
You have made many peoples lives easier cuz now all those stupid states will be gone :D!!
Thanks again, this is the best update ever!
ID:181706
 Nov 8 2009, 1:14 pm
|
|
I'm sure Tom is happy to hear that, but I've really got to give the "best release" award to 4.0. 4.0 was a huge change for the BYOND software.
| |
Yo BYOND 456, I'm really happy for you, and Ima let you finish, but BYOND 4.0 was the best release OF ALL TIME.
| |
Airjoe wrote:
Yo BYOND 456, I'm really happy for you, and Ima let you finish, but BYOND 4.0 was the best release OF ALL TIME. Lmao. I do agree with the topic starter though. Rather then simply making our games look better. 456. Makes the lives of many developers easier by not having to program/deal with hundreds of different states. Which could possibly end the era of generic byond bases (Zeta). Nice one, Byond staff. | |
WHY ISN'T MY TOP-DOWN GAME WORKING IN ISOMETRIC MODE!?
WHY ISN'T THE BETA ABSOLUTELY BUG-FREE!? GOD! | |
Kaioken wrote:
But wait, what does that have to do with the post you've replied to...? Just some silly e-drama regarding BYOND's new features. | |
Ham Doctor wrote:
What's this about different states now? How DM now handles multi-tiles. As opposed to the older versions where anything bigger then 32x32 required a massive amount of grunt work and a mixture of critical thinking. | |
Hulio-G wrote:
As opposed to the older versions where anything bigger then 32x32 required a massive amount of grunt work and a mixture of critical thinking. Actually, while you did need more work for that previously, all you had needed to replicate the current 'big native icons' behavior is a single, rather simple loop through icon_states() using pixel-offset overlays. What required much more work previously was isometric projection, which is now a matter of simply setting a variable. | |
Kaioken wrote:
Actually, while you did need more work for that previously, all you had needed to replicate the current 'big native icons' behavior is a single, rather simple loop through icon_states() using pixel-offset overlays. Stop lying, the process of trying to throw in some 4x5 animated multi-tile into dm was a pain. Except for maybe those very few programmers on Byond that sit on their ivory towers. This mentality only hinders growth. If its not obvious, its not practical. | |
No it was not.
Unless you did not notice, there has been a library out since 4.0 was released that effortlessly handles big icons. Unless you consider ticking a box a lot of effort. Also, BYOND still does not handle collisions with big icons properly, only the bottom left 32x32 square is used for collisions. Meaning there is still a lot of "gunk" involved. Unless of course you check that bigatom library box. The only difference between the old and new is that the newer one provides stuff like flick for big icons (which by the way that previously mentioned library has), and the icon editor can be used to view images larger than 32x32 (but the lack of zoom means this is only useful for moving the image around, and changing the transparency colour). Anyway, BYOND 456 is pretty good, but has some annoying issues (PINGPINGPINGPINGPINGPINGPING) and bugs that are pretty damn hard to miss. | |
The Magic Man wrote:
Anyway, BYOND 456 is pretty good, but has some annoying issues (PINGPINGPINGPINGPINGPINGPING) and bugs that are pretty damn hard to miss. Please report these on the bug tracker. We can't read minds. | |
Hulio-G wrote:
Stop lying, Why the baseless accusation? the process of trying to throw in some 4x5 animated multi-tile into dm was a pain. Since 4.0, which supported large DMIs, the process of implementing big animations (from them) became identical to the process of including normal states - which, again, was a pretty straightforward for() loop based on the icon_states() proc. You say it was a pain. Well, even if it was for you, it does not reflect it objectively. You're primarily a pixel artist, rather than a DM programmer, aren't you? I am, so trust me, I know my stuff. Point is, I certainly wouldn't argue with you about pixel-art making techniques, since I don't know enough about that. Except for maybe those very few programmers on Byond that sit on their ivory towers. This mentality only hinders growth. Eh, again with irrelevant hostility. Again, this isn't rocket science. If its not obvious, its not practical. It should come naturally to a good programmer once he realizes how the big icon was internally split into states named accordingly, and you could access those state names using the icon_states() proc. | |
The Magic Man wrote:
Unless you did not notice, there has been a library out since 4.0 was released that effortlessly handles big icons. I actually wasn't mentioning the library, which has an option for doing much more than simply having a visual-only large icon (and that's its main purpose). But even what the library does isn't all too complex in itself and there are more difficult endeavors. Also, BYOND still does not handle collisions with big icons properly, only the bottom left 32x32 square is used for collisions. That's because the 'big native icon' is a visual-only effect. Really, that new feature is almost exactly like using pixel-offset overlays (which were also boosted in 455 along the way), which is why I'm saying the ability it added isn't entirely new. The only difference between the old and new is that the newer one provides stuff like flick for big icons That was possible natively before, again with overlays/underlays. Anyway, BYOND 456 is pretty good, but has some annoying issues (PINGPINGPINGPINGPINGPINGPING) and bugs that are pretty damn hard to miss. I won't repeat what Tom said; just make sure you read the release notes and new DM Reference entries fully before reporting bugs, because there were some behavior changes that were sometimes mistaken as bugs, too. | |
I think Hulio-G likely wanted to point out that a program should be designed to fit it's target audience.
In BYOND's case, this is "people who have design ambitions but not necessarily a great deal of-- or any-- programming experience"[link]. As you said yourself, he fits that group rather better than you do, which means that the feature is very well designed and implemented (as he seems to like it). Btw. rocket science isn't really tricky, there's far worse out there. | |
What required much more work previously was isometric projection, which is now a matter of simply setting a variable. Weeeeelll, it was mostly a matter of working out the mathematics to convert to isometric tiling. Wasn't all that tricky. Making maps with the iso tiles would probably have been tricky, though. | |
Jp wrote:
Kaioken wrote: The math is actually the easy part. The layering issues are far more difficult to handle. Making an isometric game in previous versions was possible only if you did not allow gliding (by setting animate_movement to 0). With gliding in the mix, there would be no way to properly handle either the positioning or the layering. Of course tile size was also a factor, as many games wouldn't have looked halfway decent with a 32-wide tile whereas 64 is a much better size for isometric. Lummox JR | |
This thread belongs in Community.