All these animations makes my computer gasp for air when I come to this page. ._.

About time we got a 2nd page for this post. Lol.
In response to Teka123
Teka123 wrote:
wow Makeii, That is both pretty and sparkly lol. nice job :P, I'd have never though this possible with Byond in the past at least not easily.

BYOND was perfectly capable of what Makeii did before the 500 build. The difference between then and now is that we don't need to premake all of the animations of the objects growing and turning in the icon editor. You still need to create all of the objects, which really still isn't practical.

Thanks fugs, I did presume it was possible, though unsure. I knew it at least must have been a lot more simple for the programmer to make it now than previously which is cool :)
In response to Fugsnarf
Fugsnarf wrote:
Teka123 wrote:
wow Makeii, That is both pretty and sparkly lol. nice job :P, I'd have never though this possible with Byond in the past at least not easily.

BYOND was perfectly capable of what Makeii did before the 500 build. The difference between then and now is that we don't need to premake all of the animations of the objects growing and turning in the icon editor. You still need to create all of the objects, which really still isn't practical.

Which is why I wrote an object-pooling library. To make it a bit more practical.
In response to Fugsnarf
Fugsnarf wrote:
premake all of the animations of the objects growing and turning in the icon editor.
Or you could've done what I used to do: perform rotation, scaling, alpha, etc. at runtime with /icons by caching as they're made, or during a loading screen.
It would probably be more practical to place all of those particles into an object pool as Ter13 suggests. That way instead of creating and deleting particles, they are simply taken from a pool when in use, and placed back into it when finished. No extra RAM is allocated in this process.

Another disadvantage of create/delete on the fly is the extra CPU required to allocate memory and initialize the particles.

Aye, what I showed was possible before v500 (and I actually don't even use animate() in that example either so I guess my example is rather irrelevant in this thread). The example does show off atom.color and atom.transform, both new features.
Awesome stuff! Can't wait to mess with it.
So many people who are so much better than me and developing here... ._. I'm going to cry.
In response to Ter13
Ter13 wrote:
Which is why I wrote an object-pooling library. To make it a bit more practical.

This is true. I did something like this with projectiles once but it never occurred to me to do it with particle effects for some reason. That's probably because of the lack of the features we have currently, but now that those effects are much easier to accomplish, it's a no-brainer.

yep ya lost me... I like what I see but I doubt I would ever be able to use em in a game due to my lack of coding skills...
I tried playing around with animate, came up with this.
That's pretty bad ass. =O
Well, that really puts things in perspective! How much CPU does that use? Are you using a side map to do that? It would probably be a good choice, along with isometric. Now if we can just get a client screen transform, we can have something a million times more efficient than the Royal Nonesuch engine.

It's kind of strange to see sprite scaling that smooth. This effectively puts BYOND in a time period that never really got the chance to exist, because true 3D just came about too soon. I also think actual sprite scaling is a largely unexplored territory. This is similar to Mode 7 on the SNES, but a far higher quality. It may not have the capabilities of ray casting, but it still has a lot of potential.
This system works during hosted games, and depending on the rendering distance, it can get CPU intenseive.

Also, it's top down, but everything rendered is in client.screen
If you rendered it with image objects it would probably lower cpu usage a lot.
Wait what... 3D BYOND? What? *orgasm* Sorry. .__. It's just.. amazing. Didn't think this day would come! I want to cry.

Rotating Car + What Ishuri did = 3D.
Though I haven't produced any GIF, I'm going to let y'all try out a new test release of the SByIo Library V3 (though you may find several broken features until it undergoes a full upgrade).

Link: https://dl.dropboxusercontent.com/u/24250760/BYOND/ Test%20Versions/SByIo%20Library_src.zip

Previous test release used visual text objects to handle prerendered fading effects. This one utilizes v500 to perform fading (and very smoothly too). While I'm still working on the library, feel free to study the code for some new features. :P
In response to Xirre
Xirre wrote:
Wait what... 3D BYOND? What? *orgasm* Sorry. .__. It's just.. amazing. Didn't think this day would come! I want to cry.

Rotating Car + What Ishuri did = 3D.

Something like Pole Position would be a lot easier to accomplish now with transform.
Then let it be done, Fugs. Let's roll out some amazing stuff with this! :) I want to get in to it. I think this just extended my stay at BYOND by a whole lot longer. Seems interesting to pursue.

All I have to worry about, yet again, is the icons.
This isn't exactly a 500 feature project (I made it a while before 500, and just now did a couple tiny tweaks to take advantage of the new stuff, except animate()), but maybe you'd like to see it. It was made before I knew of LICEcap, so that's probably why it's gone unnoticed before.

(the title is "FPS". It's running smoothly at 30fps. Wait for the gif to load)
Page: 1 2 3