What makes programming easier or harder?

I already had a system to generate and cache at runtime icon effects like rotation, scaling, and changing alpha. That being done, using the new transforms was a matter of changing atom.IconAngle(angle) to atom.transform = turn(matrix(), angle), somewhat. Sure, transform works better resource-wise, but would using either method be any easier or harder for you if I released my system as a library, with what you have to write?

I already had system to precisely track the mouse on the screen. When you're dragging an object around on the screen, do you care what's under the mouse pointer? Not really, you already know what's there. Covering up object-specific mouse events while tracking the mouse is the only quirk with Forum_account's Mouse Position library, and it's not even an issue in that case. Plus, we're working with the exact same data to track the mouse in the library as with native. How we use it doesn't change.

Better? Sure!
Easier? Not necessarily.


And to reiterate, billiards in particular requires absolutely none of the new features. Accurate pixel movement, special collision handling (detection and resolution), and slingshot mouse control were all doable before 500. Accurate pixel movement systems have been made before 4.0, and as far as I can tell, precise mouse detection was possible as soon as icons supported alpha transparency. Using these systems has no effect on the difficulty of programming because since they already exist, you don't have to go through the trouble of creating them.

Calculating what happens to two circles of equal mass, moving at any speed, colliding at any angle is difficult for me. But once I have it, I shouldn't have nearly as much difficulty incorporating it in any colliding circle-based games.

I'm not trying to say that this thread isn't awesome, it is. I'm just pointing out that people apparently don't know how to use libraries or reuse code or write code to be reusable.
Dan and Tom and Lummox JR all make mistakes in their code. The BYOND engine is effectively the same as a library. Why do people treat user-made libraries so differently?

The BYOND engine is effectively the same as a library. Why do people treat user-made libraries so differently?

Maybe because the libraries are lacking in quality and modularity? Forum_account released some of the best libraries ever in BYOND, but for the most part it goes downhill from there. Even some of his libraries were buggy and incomplete in some aspects. Basically, you just can't expect the same level of quality from a library as you can from a native implementation.

95% of the time, I will use a library just to get ideas on how to implement things (assuming relevent library even exists), then proceed to rewrite the functionality myself, from the ground up, because the library is never really capable of doing exactly what I need, and is just too inflexible to modify.

With native procs, I don't usually run into that kind of issue. They are modular, flexible, and are often capable of doing exactly what I want. While the native implementations are not perfect, and there is always more that can be done with softcode, in most cases you would have to write everything yourself, since the libraries are not usually good enough to actually include in your game. Sure, you can throw together a bunch of poorly designed libraries, and make a game out of it, but that would just be a completely careless and lazy thing to do. Personally, I will accept nothing less than exactly what I want for my games, so libraries don't always help that much.

So, with a lack of great libraries, yes, native implementations like this make it easier to do things.

That's why I mentioned the programmers of the native implementations and that they make mistakes too, just like anyone else who creates libraries. Have you seen the Bug Reports forum? Or the Feature Requests? Libraries often have those forums too, in their hubs.

Sure, libraries have issues. But so does the BYOND engine, and every piece of software ever. No one is perfect. This includes Tom and Lummox.

Native implementations are generally better than libraries.

It's kind of a moot point, though. Not everything you are going to do is going to need to be implemented into the language, so libraries that are adequately designed are going to have some use.

Post more cool shit and stop talking.

Kaiochao wrote:

Every time I mention pool physics, someone has to chime in with circle-circle collision detection. I mean, come on.

I'd have done this long ago if I could take the time to learn/implement circle-circle collision. It (and some things shown off in this topic) requires none of the new stuff, though.

This is why I posted the link in reference to Billiards physics. Just trying to help o__o

Kaiochao wrote:

I think you're ignoring the work that Lummox JR did to make things native.

It's not ignoring that work. It's knowing that someone else doing the work = I don't have to. Right?

Maybe i'm putting words into his mouth, but Flick's statement that triggered this digression meant that the new built-in proc makes these things easier for the developer. sure, the underlying implementation is more or less the same level of work/difficulty, but now, all of that work has been done, ahead of time, by someone else.

If I released my icon effects system as a library for anyone to use, how much work do you do in using that, compared to the amount of work you do to use the now-native system?

Likely no difference. Of course, there is the negligible amount of effort to find, download, and include the library vs. just having the functionality already there.

I like to think I made mine easy to use, and Lummox probably thinks his is easy to use as well. You mention there being a lot of code involved to perform an icon operation. None of that actually matters because what you end up writing is a single proc call, in either system.

No, you end up writing several lines of code if you DIY. At least once; even if you can from then on call the function in a single call, you still had to write the function in its entirety at some point.

The point here is that someone other than you already did the work. What's the difference in the code utilizing it? Especially in the case of mouse tracking, it's exactly the same.

When using a proper library, you call a proc to do X.
When using a "built-in feature," you're calling a proc to do X.
You didn't have to write the library.
You didn't write the native implementation.

It's exactly as you said. Do it all with a single function call. How is that any different than doing it all with a function call from a library?

You're right, there is no difference between using a built-in function and using a similar function from a library (you're also correct that the "built-in" functions are more or less pre-included libraries themselves)

But that is assuming that you have such a library. In the case of animation effects, is there an existing library that works as cleanly, simply, and as powerful as the newly added animate() (and related support features)?

If there's not, then all developers up to this point have had to do it "manually" by cobbling together a string of various sub-functions (icon manipulations, and the manual assigning of the new icons to the atoms, with the appropriate delays between each "frame")

Again, much more work = harder (maybe "less convenient" is a better term?).

Now that there's a convenient, right-there function that can cram a library's worth of code right into a single line (again, from the perspective of the prospective developer)

How is it not now easier for developers to do these things?

And it doesn't matter when someone did the work, either. Even if a developer is re-using their own library, they still did all of that work at some point. Now, no one has to even go that far.

Kaiochao wrote:

All right. So, by "no one," we're still talking about Lummox.

No, we're not talking about Lummox. We're talking about the end-users. None of us now have to bother designing or writing our own icon animation functions (or even finding and implementing a library)

It doesn't matter to the end user who did the work, as long as it's not them.

This stuff is now much easier to add to a project.

Are you seriously disagreeing with that very simple and plain fact?

Ter13 wrote:

...I wish I had a spiffy gif to post using the new features right now...

I've been wondering what program Flick, among others, uses to get these fancy gifs as well

Something as simple as shrinking and fading my blocks makes it look so much better.