Torque2D ShowOff();

#21 Push the duck into the drain:

https://github.com/practicing01/Rubberto_Duckie

#22 It's cool seeing someone already working with my LiquidFun integration. Due to the speed and white particles, it's kind of difficult to see your interaction. I get the goal of the game, but how is it being controlled?

#23 An invisible kinematic rectangle being moveTo'd from offscreen, inwards at the angle from the center of the screen towards the mouse click.

#24 Soft body physics WIP

#25 Ok, I'll bite - how are you simulating the soft body physics over a single texture? Pretty neat effect.

#26 Once the implementation is stable and contains more feature, I'll post the full source to my work. For now, I can summarize what I'm doing.

I've created a new C++ class which inherits from SpriteBase. In this class, I have a Vector of SceneObject* and a stand-alone SceneObject. The stand-alone acts as the hub of the circle. The rest are generated based on a radius and a segment count. I essentially create a bicycle wheel. The "spokes" are simple distance joints. Each outer object is connected to its neighbors and the hub via the joints. That alone will give you a squishy circle in T2D.

That takes care of the simulation side. The rendering is custom in the ::sceneRender() function, I generate vertices and texture coordinates based on the position of the objects that were generated. I then use a simple GL triangle fan operation to render each "segment" of the squishy object. So whenever the objects move, the vertices and texture coordinates will change accordingly.

Because it derives from SpriteBase, it automatically contains an Image field for assigning an ImageAsset. The end result in script is this:

%softBody = new SoftBodyObject();
%softBody.Image = "ToyAssets:Football";    
%softBody.Position = "0 0";
%softBody.Radius = "50";
%softBody.SegmentCount = "20";
%softBody.SegmentSize = "0.15";
%softBody.Spring = "4";
%softBody.DampingRatio = "0.5";

Just like that, you have a squishy soft body object in script with zero hassle.

#27 Very cool!

#28 More casual badness:


https://github.com/practicing01/Phyxel_Tender

#29 Casual yet again:
https://github.com/practicing01/Spooks_VS_Mounts

#30 Casual :(. A hardcore game is on my to-do list.
github.com/practicing01/Carambola

#31 I've decided to rewrite, simplify, improve my Dots_and_Crits sandbox to make it easier to understand for modders (including myself hehe). This project will take me a long time so I won't be posting videos that often unless I implement show-worthy things like this:


I suddenly got the urge to try and replicate the PS2 menu screen effects. Found a tutorial for software 3d programming:
www.khanacademy.org/cs/3d-tutorial-4/1648921303

Link to TS code:
github.com/practicing01/Dots_Net_Crits/blob/master/modules/Module_Lobby/assets/s...

#32

#33 I love where your game is going practicing01. Keep it up!

#34 This game - but only check out the modules.



The reason I say that is I don't think the engine source is up to date - not sure if I've managed to get this properly synced with the upstream....

Nevertheless, I've tested and it appears that it works with T2D 2.0 and 3.0.

Less of a "show off" and more of a "show how" - there are some bits for managing game events, a Behavior Template, example particle effects, input handling, overly-complex object/behavior/script class interactions, etc.....

#35
It doesn't look like much so I'll explain. On the right, TGB running on an XP VM in Mint Linux. On the left, a T2D MIT sandbox toy that parsed the TGB level file. Wasn't difficult since it's just text. I didn't want to go into tilelayer parsing since it's in binary. There are many ways to go about porting but I think that it's a lot easier than writing tools. Not sure of the legality of releasing the parser.

#36 @Richard - Loved the Nyan Cat. It made me smile.

@practicing01 - Now that is very cool. I'm sure many people would bow at your feet for a full TGB project converter. The hardest part is truly the binary files for the particles and tilemaps. However, believe it or not, these would actually be pretty easy to pull off if you read the C++ source and the docs Melv wrote for legacy TGB. Just requires quite a bit of careful TS scripting and wading in the murky waters of TGB editor setup.

#37 This is actually an older build of T2D 2.0, but I just now got around to pulling it out again and doing a video capture. I had started playing with converting a platformer concept I'd started in TGB but was struggling with one-way collisions via the Box2D physics. Took a little time and research but it was holding up pretty well so far.

#38 One-way collisions had me confused - I was under the impression that edge collision shapes only collided on the "front" but I was mistaken. Could you describe your method for achieving this?

#39 It's a change to engine code, but not a very complicated one.

I actually found some helpful tips at http://www.iforce2d.net/b2dtut/ It's centered around Box2D specifically, but most of it still applies to the Torque implementation. Check under the 'Advanced' section for One-way walls. They were able to get more out of the code than I could (They actually have moving platforms/walls that you can walk through on one side but push you around on the other, etc... I didn't have much luck with implementing those, but I did get a basic horizontal platform to work for me).

I'll look up the specific code changes tomorrow, but its basically setting a Torquescript variable on a body that can be read in the engine code when determining how to handle a contact. If its one way and the normal of the contact suggests they're approaching it from the solid side, then you handle the collision. If they're approaching it from the passable side, you ignore the contact and let them pass through.

It's not foolproof, but its pretty solid right now as long as they jump high enough to clear the platform. If they don't end the contact so they can begin a new one on the way down, then they'll fall right back through - which is usually how platformers address it anyway.

#40 Interesting. In the physics guide, it is written that edge and chain shapes are ideal for one way collisions - I had assumed this was something built-in to Box2D and that the engine had access to it. I'll have to remember to look at this sometime in the future, might be nice to include as a feature.

Nice video by the way!