Jump to content


Photo

TweenGMS -- Tweening Engine


  • Please log in to reply
267 replies to this topic

#1 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 01 April 2013 - 09:08 PM

tgms_forum.png
 

[Marketplace Versions] 

TweenGMS Pro | TweenGMS Lite

 

Original Version (unsupported)

 

HTML5 Demo

 

[ Info ]

TweenGMS is a feature-rich tweening engine which is both easy-to-use and flexible.

With nearly 3 years of development, it offers many essential and advanced features powered by an optimised codebase.

Quickly improve the look of your games by tweening movements, fades, rotations, animations, paths, stats, and much more!

 

If you don't know what tweening is or why you should use it, check out this video (Youtube)

 

(Visit easings.net for info regarding standard easing functions)

 
[ Features ]

  • Fire-and-forget tweening
  • Step and seconds(delta) timing
  • Play modes (once,bounce,patrol,loop,repeat)
  • State control (pause,resume,stop,finish,reverse)
  • View, tile, path, background, and data structure support
  • Custom variable easing
  • Advanced callback system
  • Time scale contol (global and per-tween)
  • Heavily optimised
  • Delayed tweens
  • Control groups
  • Stepping (forward and back)
  • Supports all platforms
  • Automatic memory and persistence handling
  • Examples and game project included
  • And more...

Edited by 8BitWarrior, 21 October 2015 - 01:13 AM.

  • 18

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#2 Tarik

Tarik

    GMC Member

  • GMC Member
  • 2731 posts
  • Version:GM:Studio

Posted 01 April 2013 - 09:46 PM

Great work!

 

For some of the simple and lightweight tweening jobs, GMLscripts has a bias and gain script which are great. e.g.: www.gmlscripts.com/script/gain_fast 


  • 0

#3 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 2026 posts
  • Version:GM:Studio

Posted 02 April 2013 - 02:57 AM

The tweens themselves look good.  One thing I think you could use(if you haven't done it) is to be able to tween between two values, using all of the easing functions you have.  It would work like LERP but easing instead, and then we could use it to apply to whatever we want it to.  The problem with this as far as creating it is how to affect a variable on an object.  For example, the scale, x/y, alpha, color, all of those things, is pretty easy to have work automatically because you know beforehand what variable you are affecting.  The only way I see to do this would be to create a "tween" and then return the current value of that tween to a variable, but that makes it less automatic.

 

In any case, I'd also recommend you turn this(when you are done and work the bugs out) to an extension.  That is the ultimate way to make this kind of thing easily accessible to us, and since it is all gml, it should currently work on all platforms GMStudio supports, even now before the version 1.3 comes out.


  • 1

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#4 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 02 April 2013 - 07:53 AM

In any case, I'd also recommend you turn this(when you are done and work the bugs out) to an extension.  That is the ultimate way to make this kind of thing easily accessible to us, and since it is all gml, it should currently work on all platforms GMStudio supports, even now before the version 1.3 comes out.

 

Thanks for the feedback. I hope to turn this into a .gex extension after some needed design changes.

 

Since references or pointers don't exist in GM, the tweening system simply matches instance IDs with scripts which affect the desired value.

myVar = argument0;

Its a tad clunky, but I've been happy with the overall performance. I have included "reference" scripts for the most common needs, but have been forced at this point to let others extend them for any other values they need. However, I'm starting to lean towards switching to a ds_map for referencing values instead. I think it would be much easier for users to extend, and hopefully maintain a reasonable amount of performance.

 

And by a function like lerp, would you mean something like...

value = Ease(value1, value2, amount, algorithm);

 

I just added that in now, and am realizing I should have done so sooner :)

 

But yeah, you've got me thinking some things over. Thanks!


Edited by 8BitWarrior, 04 April 2013 - 07:32 PM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#5 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 2026 posts
  • Version:GM:Studio

Posted 02 April 2013 - 03:47 PM

Yeah, I made that post without paying any attention in detail...you already had worked around the "lack of pointers" problem with scripts, which makes sense, and is probably what I was going to end up having to do.  In fact, I'd say that it is probably the the easiest way to get "custom" variables done.

 

And yes, the function you added is pretty much what I was talking about.  It would allow some flexibility in things for when the "automatic" tweening won't cut it, for example in cases where at random times we may need to "track back" the tween, since it would be easier to back track than to create a new tween.

 

Once you work it out, I await the gex, and assuming you are going to make this an open source(or simply free to use) extension, it will save me much work of creating my own.


  • 0

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#6 NeutralD

NeutralD

    GMC Member

  • GMC Member
  • 28 posts
  • Version:Unknown

Posted 04 April 2013 - 11:18 AM

Could you, please, post it in gmz file format. I have an error: "Invalid path…"


  • 0

#7 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 04 April 2013 - 07:27 PM

Could you, please, post it in gmz file format. I have an error: "Invalid path…"

 

I have changed it over to the .gmz format.


  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#8 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 08 May 2013 - 05:39 AM

TweenGMS has been updated to v0.87 and now implements the tweening scripts as a GEX extension.

The system is now easier to use and includes various bug fixes and optimizations.


  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#9 Kensai_

Kensai_

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 10 May 2013 - 05:38 AM

Hey, great work, man! I'm always checking back to see what new developments have been made with your work, and I'm liking it more and more with each new update. I think I'll use this in my current project outright.

 

I do have a question, though. I have the following in a mouse enter event:

if (!TweenIsActive(tween_y)) {
   TweenPlayBounce(tween_y, y__, y, y + sprite_height / 4, 3, EASE_OUT_CUBIC);
   TweenPlayBounce(tween_yscale, image_yscale__, image_yscale, image_yscale * 0.75, 3, EASE_OUT_CUBIC);
   alarm[0] = 6;
}

And this in Alarm 0: 

TweenPlayBounce(tween_y, y__, y, y - sprite_height / 4, 5, EASE_OUT_CUBIC);

But this creates a strange situation where each time I hover the object with the mouse, it goes a bit further down the screen. Apparently this happens because by the time the alarm0 event is fired, the yscale tween has not finished and consequently sprite_height is not yet back to normal. Strangely the whole package behaves well when I put alarm[0] = 7 but that... doesn't seem to make much sense since the first tweens occur back and forth once, each one taking 3 steps (plus, it seemed to work fine in v0.86a).

 

EDIT: 

Also, I managed to understand the ExecuteEase() function, thanks to this, but I don't quite understand the meaning of Ease() itself. Could you explain? Sorry for the bother.


Edited by Kensai_, 10 May 2013 - 07:36 AM.

  • 0

#10 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 10 May 2013 - 11:59 AM


But this creates a strange situation where each time I hover the object with the mouse, it goes a bit further down the screen. Apparently this happens because by the time the alarm0 event is fired, the yscale tween has not finished and consequently sprite_height is not yet back to normal. Strangely the whole package behaves well when I put alarm[0] = 7 but that... doesn't seem to make much sense since the first tweens occur back and forth once, each one taking 3 steps (plus, it seemed to work fine in v0.86a).

 

EDIT: 

Also, I managed to understand the ExecuteEase() function, thanks to this, but I don't quite understand the meaning of Ease() itself. Could you explain? Sorry for the bother.

 

First off, thanks for the feedback. Its greatly appreciated and helpful.

 

I think I know why this issue is happening. First, TweenPlayBounce() will actually take twice as many steps to finish as TweenPlayOnce(). Currently, the duration parameter determines how many steps it will take before the tween starts to bounce back. Bad design on my part, maybe? Anyhow! As a result, the first tweens finish JUST before alarm[0] is called. This prevents the alarm event from being executed since !TweenIsActive(tween_y) is once again true and the mouse enter event once again sets alarm[0] to 6.

 

I see a change I need to make. I currently have the tweening system's main update running from an alarm event set at an interval of 1. I will be changing the system to use a normal step event instead. That should fix this issue and prevent other similar problems I could see arising.

 

As for ExecuteEase(), I didn't expect anyone to use the functions starting with 'Execute', but of course, you can if you want. Ease() is what I intended people to use. Infact, Ease() is basically just a wrapper for ExecuteEase().

Ease is similar to the function lerp(), except that it receives an extra EASE_CONSTANT argument.

 

lerp(val1, val2, amount);

Ease(val1, val2, amount, EASE_CONSTANT);  -- OR -- Ease(x1, x2, time [0.0 - 1.0], EASE_CONSTANT);

 

For example, both of these functions will return a value of 25:

x = lerp(0, 100, 0.25);
x = Ease(0, 100, 0.25, EASE_LINEAR)

Changing the EASE_CONSTANT will likely cause Ease() to return a different value.

I use Ease() in the demo project for drawing out multiple points of a tween within its range. It would not be possible to do that with the automated tweening system.

 

Anyhow, hopefully that makes sense. Feel free to let me know if you find any other issues or have general questions and/or feedback :)


Edited by 8BitWarrior, 16 May 2013 - 08:17 PM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#11 Kensai_

Kensai_

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 10 May 2013 - 09:40 PM

Thank you for your response, I finally understand Ease()  :)

 

Oh, I also wanted to ask you if you might consider making a "Tween queue" and/or a "Tween schedule". I sometimes find myself in the need to execute a group of tweens right after another. In this case I ended up using the alarm event to do so, so it's not really necessary, but it would be very useful! It's just a thought.


Edited by Kensai_, 10 May 2013 - 09:45 PM.

  • 0

#12 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 11 May 2013 - 08:04 PM

 

Oh, I also wanted to ask you if you might consider making a "Tween queue" and/or a "Tween schedule". I sometimes find myself in the need to execute a group of tweens right after another. In this case I ended up using the alarm event to do so, so it's not really necessary, but it would be very useful! It's just a thought.

 

I am hoping to have another update out in a couple of weeks. If all goes well, I'll look into implementing a schedule system.


Edited by 8BitWarrior, 11 May 2013 - 08:04 PM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#13 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 14 May 2013 - 07:05 AM

TweenGMS has now been updated to version 0.87b.

 

Notable changes:
- Added delayed tweening functions. e.g. TweenPlayOnceDelay();

  *** Naming convention may change in future versions
- Changed TweenSystemIsPaused() boolean to TweenSystemIsActive()

- Slight boost in overall performance

- Bug fixes

  *** TweenPlayLoop() and TweenPlayRepeat() no longer broken.


  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#14 Kensai_

Kensai_

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 23 May 2013 - 05:25 PM

What a pleasure!  :)  Many thanks for your great contribution.

 

A small tidbit, the Documentation folder in the zip has a typo: It says Documenation, lacking one t


Edited by Kensai_, 23 May 2013 - 05:31 PM.

  • 0

#15 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 23 May 2013 - 07:10 PM

 

A small tidbit, the Documentation folder in the zip has a typo: It says Documenation, lacking one t

 

Thanks for pointing that out. I'm sure it doesn't look great when the very first part to the documen(t)ation has a mistake :sweat:

And, thanks again for the supportive feedback!


Edited by 8BitWarrior, 23 May 2013 - 09:09 PM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#16 alexandervrs

alexandervrs

    GMC Member

  • GMC Member
  • 745 posts
  • Version:GM:Studio

Posted 31 May 2013 - 12:05 PM

This is extremely nice, however it is a bit too much for my needs.

 

I am trying to just ease out some elements, however I am a bit confused on how to setup an easing to work with GM, I was using the EASE_OUT_QUAD algorithm in a script called _ease_out_quad()

 

In what way I can just move an object to a position with easing?

 

Also TweenPlayOnce(tween_y, y__, -sprite_height, room_height*0.5, 60, EASE_OUT_BOUNCE); the y__ argument looks a bit weird,

wouldn't TweenPlayOnce(tween_y, 'y', -sprite_height, room_height*0.5, 60, EASE_OUT_BOUNCE); look better?


Edited by alexandervrs, 31 May 2013 - 03:17 PM.

  • 0

#17 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 31 May 2013 - 07:34 PM

I am trying to just ease out some elements, however I am a bit confused on how to setup an easing to work with GM, I was using the EASE_OUT_QUAD algorithm in a script called _ease_out_quad()

 

In what way I can just move an object to a position with easing?

 

Also TweenPlayOnce(tween_y, y__, -sprite_height, room_height*0.5, 60, EASE_OUT_BOUNCE); the y__ argument looks a bit weird,

wouldn't TweenPlayOnce(tween_y, 'y', -sprite_height, room_height*0.5, 60, EASE_OUT_BOUNCE); look better?

 

In a future update, I am looking to include a function for simply moving objects to a position. It would look something like:

TweenSimpleMove(start_x, start_y, destination_x, destination_y, duration, EASE_CONSTANT);
// or maybe more simply
TweenSimpleMove(destination_x, destination_y, duration, EASE_CONSTANT);

Right now, to do the same is:

tween_x = TweenCreate(id); // First create automated tween reference (create only once)
tween_y = TweenCreate(id);

// Move Right and Up by 100 pixels over 30 frames (1 second)
TweenPlayOnce(tween_x, x__, x, x+100, 30, EASE_LINEAR);
TweenPlayOnce(tween_y, y__, y, y+100, 30, EASE_LINEAR);

The demo .gmz project included with the project shows various examples.

If I am misunderstanding your question, do let me know! I'm always trying to make this system easier to use.

 

Script constants (x__) being used, instead of string constants ("x"), is largely a performance issue. Using a switch statement with string constants to look up the appropriate variable is fine with short strings like "x", but when you use "image_alpha" or other longer strings, the performance takes a hit.

 

I'd love to use string constants, but unless I can find a way to increase performance, I will need to stick with assigning and executing script constants. The performance would be fine when using a few tweens at once, but in the case that hundreds are needed at once, using script constants is beneficial. However, when GameMaker:Studio 1.2 is released, I will take another look at string constant performance. 

 

The appending double under score "__" is used to prevent potential naming conflicts with other variables, such as when people declare local variables as var _x; or var x_;

 

You could change the var setter script constants to anything you like. e.g. Set_x, _x_, Var_x, Tween_x, SuperAwesomeX. It would then be up to you to stay consistent with whichever convention you use.

TweenPlayOnce(tween_y, Set_y, -sprite_height, room_height*0.5, 60, EASE_OUT_BOUNCE);

TweenGMS still has its flaws. But, I'm hoping to clean up some conventions and fix some potentially critical bugs (Doesn't play nice with deactivated objects) over the next few updates.


  • 1

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#18 Kensai_

Kensai_

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 31 May 2013 - 09:33 PM

Yes, please. Don't use magic strings. I very much prefer the y__ to magic strings.

 

On a somewhat related note, I do not understand how it is possible for you to pass a function as a parameter. I haven't found any resources regarding this particular functionality of GML. How does that work?


  • 0

#19 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 01 June 2013 - 12:45 AM

Yes, please. Don't use magic strings. I very much prefer the y__ to magic strings.

 

On a somewhat related note, I do not understand how it is possible for you to pass a function as a parameter. I haven't found any resources regarding this particular functionality of GML. How does that work?

 

At this point, I have my doubts that strings will ever be used. What I do hope for, is the ability to pass variables as a reference or pointer. That would make things even cleaner and more efficient.

 

As for how scripts are passed as a parameter...

Like objects and sprites, a script's name is simply a constant value used to access the appropriate asset. By leaving off the () at the end of the script, we simply access that constant value instead of actually calling the script's code. This value can in turn be used by script_execute(script, arg0, arg1, arg2, ...) to call a script with the supplied script constant and optional arguments.

 

For Example:

// Call script directly
value = Double(2); // 4

// Get constant value for accessing Double() script
scriptDouble = Double; 

// Use script constant stored in scriptDouble to call script
value = script_execute(scriptDouble, 2); // again... value = 4

Infact, script_execute(Double, 2) and Double(2) would also do the same thing. Although, script_execute(Double, 2) would be redundant in this case.

 

However! This does not work for built-in gml functions or GEX scripts! (This limitation created a bit of a headache when turning TweenGMS into a GEX). In order to get around that, you have to wrap the function in a new script. For example, if you wanted to pass instance_create(x, y, object_index), you would need to create a new script which looks like this:

// wrapper for instance_create()
return instance_create(argument0, argument1, argument2)

When wrapping existing gml functions, I typically name the new script by capitalizing the first letters from the original script . e.g. instance_create becomes Instance_Create.

 

Anyhow, this functionality is REALLY useful. For example, I also use it for a generic button class which contains a variable, called onTouchUp, which holds a script's constant to be executed later when a user touches up on a button. This allows me to create multiple buttons from a single obj_UIButton class, and dynamically attach to it unique scripts at runtime.

 

I suppose I could release my UIButton and delegate system, as well. Perhaps people would find that useful :)


Edited by 8BitWarrior, 01 June 2013 - 01:30 AM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#20 Kensai_

Kensai_

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 02 June 2013 - 06:34 AM

I had no idea it worked that way til now. Clever way of using it with the UIButton, I'm pretty sure it would be useful :)

 

I'd give you reputation but I have no idea how that works in these forums.


  • 0

#21 alexandervrs

alexandervrs

    GMC Member

  • GMC Member
  • 745 posts
  • Version:GM:Studio

Posted 03 June 2013 - 07:46 AM

If I am misunderstanding your question, do let me know! I'm always trying to make this system easier to use.

 

Ah, I was talking more of explaining how things work with easing and such, but is fine. Had a friend explain it to me. :)
 

 

Yes, please. Don't use magic strings. I very much prefer the y__ to magic strings.

 

Looking at the tween class that Flash has, 

var myTweenX:Tween = new Tween(myMovieClip, "y", Strong.easeOut, 0, 300, 3, true); 

it does use strings like 'y' to determine which property to tween. For one though I didn't know you could use scripts like that, without parentheses in the end.
As long as it doesn't break the game, should be fine anyway. For performance issues, it is acceptable.

 

TweenGMS still has its flaws. But, I'm hoping to clean up some conventions and fix some potentially critical bugs (Doesn't play nice with deactivated objects) over the next few updates.

 

Well, I think it is pretty awesome so far, a feature that should be built-in to GM in the first place. :)


Edited by alexandervrs, 03 June 2013 - 07:48 AM.

  • 0

#22 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 14 June 2013 - 12:02 AM

The next update for TweenGMS should be out in a couple of weeks. I have done a large overhaul to the inner workings of the system, making it much more optimized and polished overall.

 

But, before releasing it, I want to mention some new functions and to get feedback on some potential changes.

 

#1 

The new update will include a new group of simple functions:

 

TweenSimpleMove()

TweenSimpleFade()

TweenSimpleScale()

TweenSimpleRotate()

TweenSimpleImageCycle()

TweenSimpleAccelerateScalar()

TweenSimpleAccelerateVector()

 

These functions can be used by themselves, and do not require the use of a reference from TweenCreate(). However, they can not be manipulated once they have been started. With the exception that they will still be affected by TweenPauseAll(), TweenResumeAll(), etc. As well, they will belong to group 0, so that they could be manipulated with the group functions as well.

 

 

#2

I've added a function to allow for the ability to prevent deactivated instances from having their tweens automatically destroyed:

TweenSetAutoDestroy(boolean)

In such a case, however, it is up to the developer to re-enable auto destruction later, or to call TweenDestroy() manually. Failing to do so would likely result in a memory leak.

 

I have since found a better way to automatically handle deactivated/reactivated instances which use tweens. Users shouldn't need to worry about this anymore with the next update.

 

 

#3 

I am considering changing how specific ease functions are accessed. Right now, constants are used, such as EASE_IN_OUT_CUBIC. However, I am playing with the idea to have them work like the variable/property setters, e.g. x__, image_alpha__.

 

This would leave the scripts exposed, and not part of the actual GEX. They would need to be imported like the variable/property scripts, and accessed using their constant script names instead. This would make a tween function look like:

TweenPlayOnce(tween_x, x__, 0, 100, 30, EaseInOutCubic);

This has the benefit of allowing others to more easily customize existing ease functions, or to add their own. It would then be up to you to manage which ease functions you want included with your project. The extra benefit with this method would be a slight performance gain overall.

I have since decided to leave the ease constants as they are. If people really need to customize or add ease functions, they can modify the ExecuteEase script contained within the GEX and add their own constants to access them. Plus, I found that the current method is actually faster than the method I was considering.

 

 

Feel free to give feedback on this, or to let me know if there is anything else you would like to see added to TweenGMS.


Edited by 8BitWarrior, 16 June 2013 - 07:56 AM.

  • 1

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#23 Slammin Sam

Slammin Sam

    I craft juicy things

  • GMC Member
  • 854 posts
  • Version:GM:Studio

Posted 14 June 2013 - 01:32 AM

Words cannot express how amazing this is :D 

 

EVERYONE should be using this extension, if not a very similar one. It makes your games looks 10x as professional.

 

I'll certainly be donating when I get my game out there!

 

Thanks 8bitW


  • 1

Nothing to see here...move along


#24 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 14 June 2013 - 09:49 PM

Words cannot express how amazing this is :D 

 

EVERYONE should be using this extension, if not a very similar one. It makes your games looks 10x as professional.

 

I'll certainly be donating when I get my game out there!

 

Thanks 8bitW

 

Thanks! The support is encouraging.

I look forward to making this system even better. :)


Edited by 8BitWarrior, 15 June 2013 - 07:38 AM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#25 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 17 June 2013 - 07:29 AM

Version 0.88 has been released!
 
I believe this version is by far the most stable. But, feel free to correct me if I'm wrong :)
 
Here are the Update Notes:

Spoiler


Edited by 8BitWarrior, 17 June 2013 - 08:07 AM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#26 Indecom4000

Indecom4000

    GMC Member

  • GMC Member
  • 1636 posts
  • Version:GM:Studio

Posted 17 June 2013 - 08:51 AM

Hey this is pretty nifty :)


Edited by Indecom4000, 17 June 2013 - 08:53 AM.

  • 0

LD-Logo-sml.png


#27 Kensai_

Kensai_

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 17 June 2013 - 05:20 PM

Awesome work, as always! Maybe in the future you could share your UI button with us  :P


Edited by Kensai_, 17 June 2013 - 05:24 PM.

  • 0

#28 phocker

phocker

    GMC Member

  • GMC Member
  • 86 posts
  • Version:GM:Studio

Posted 17 June 2013 - 05:26 PM

I must say this is an awesome library. I was able to use it very quickly and the documentation is very well done.

 

One request I would have is the ability to assign multiple delegates (callbacks) to a completed tween. I realize that this might be technically impossible without some kind of robust message callback system in place first.

 

Thanks again for the great library.


  • 0

promo_banner.png

 

SpockerDotNet LLC Website


#29 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 17 June 2013 - 05:35 PM

One request I would have is the ability to assign multiple delegates (callbacks) to a completed tween. I realize that this might be technically impossible without some kind of robust message callback system in place first.

 

Actually, I will put that on the roadmap. It probably won't make it in any time soon, but it is totally doable. I need more free time to tinker around with it but need to finish up a freelance job first. :sweat:

 

 

Awesome work, as always! Maybe in the future you could share your UI button with us  :P

 

I'll see what I can do :)


Edited by 8BitWarrior, 17 June 2013 - 10:14 PM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#30 Jobo

Jobo

    Second-Scum-Of-The-Earth

  • YoYo Games Staff
  • 3000 posts
  • Version:GM:Studio

Posted 18 June 2013 - 02:29 PM

I had a quick look at it, and it all seems overly complicated for what it does...

An object with crazy amounts of list/grid checking, the entire "system" as a secret extension meaning you have absolutely no idea how badly it might impact your performance compared to other solutions (that put me off instantly), and generally lots of weird scripts in the example...

 

Sorry but I wouldn't consider using this, and now you know why.


  • 0

My posts are my own views and opinions... Unless they are yours too, in which case I think you're a very intelligent and handsome individual (I think you are anyway!)


#31 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 18 June 2013 - 06:51 PM

I had a quick look at it, and it all seems overly complicated for what it does...

An object with crazy amounts of list/grid checking, the entire "system" as a secret extension meaning you have absolutely no idea how badly it might impact your performance compared to other solutions (that put me off instantly), and generally lots of weird scripts in the example...

 

Sorry but I wouldn't consider using this, and now you know why.

 

Thanks for taking a look at it.

 

Rolling your own solution would, of course, be the most efficient method. But, I have worked on finding the most efficient way to implement an automated system while attempting to keep it as stable and user-friendly as possible.

I have been using this for all my projects, and am quite happy with its performance. I am always running stress tests to see how much I can throw at it. Currently, I benchmark roughly 5000 active tweens at once before my computer drops below 30fps (My computer is not super fast). With LLVM coming soon, I suspect that number to increase to around 25,000 - 50,000+. How much extra performance do we need at that point?

 

If people need to avoid the shared_Tweener's overhead, Ease(value1, value2, amount, algorithm) can be used to manually tween values, without shared_Tweener being instantiated. The instance will never be created until at least one automated tween script is called. Once a room ends, the tweening system is destroyed, unless a persistent instance is using the system.

 

This system is, purposely, meant to be a sort of black box. The point to making it was so that people don't have to think about why/how it works. However, since it is a GEX implemented through GML, all of its internals are accessible if people really want to dig into it and find out what is going on underneath.

 

As for the example project, it still needs to be cleaned up a bit and generally documented better.


Edited by 8BitWarrior, 19 June 2013 - 02:50 AM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#32 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 2026 posts
  • Version:GM:Studio

Posted 18 June 2013 - 07:29 PM

I understand your viewpoint 8bit.  I have some of the same issues in my kbinput extension.  Back when you could define objects via gml code, I had it automatically creating the object that would control the updating, and the user never had to update or anything, but they would have to call a function to reactivate it if they had a mass deactivation.  I also understand about trying to do automatic and efficient at the same time.  I have some grids in use in my kbinput extension as well, and there is plenty of moving/accessing being done "under the hood.."  So far, it hasn't given my any performance problems, but I'm guessing it may be part of why my extension hasn't been all that popular either.  Who knows?

 

I too am waiting for LLVM compilation to come out.  I pretty much have vertex animation(3d) working good, but it won't be very fast with multiple models, and LLVM is going to be a godsend for these kinds of things.


  • 0

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#33 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 19 June 2013 - 05:47 AM

So far, it hasn't given my any performance problems, but I'm guessing it may be part of why my extension hasn't been all that popular either.  Who knows?

 

I too am waiting for LLVM compilation to come out.  I pretty much have vertex animation(3d) working good, but it won't be very fast with multiple models, and LLVM is going to be a godsend for these kinds of things.

 

It looks like you have got positive responses for your extension. I don't think performance would be hurting it, but people, simply, failing to realise its benefits and the time it would save them.

 

But yeah, when it comes to designing tools for realtime application, I like to balance things between 51% usability and 49% performance. When a compromise can't be made between them, user-friendliness wins. At the end of the day, I want to make something that doesn't frustrate people, while being fast enough for at least 9 out of 10 cases.


  • 1

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#34 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 2026 posts
  • Version:GM:Studio

Posted 19 June 2013 - 06:07 AM

Positive responses yes, but I think maybe more would use it if it wasn't as closed.  I actually don't have a problem sharing the code, but some people either prefer to only use what they themselves have written, or want more customized solutions to any given game, and your(and mine) extensions are more built for general usage.  I don't feel bad though, because the real purpose of the extension for me was exactly that, for me, and if the community wants to use it, fine, and if not, what can I do?  If it were because of lack of documentation, support, or functionality, it would be one thing, but considering it isn't any of those things, it is fine with me.  On the other hand, I'd bet when I'm done with my 3d vertex animation extension it will become quite popular, mainly because it is something that is in much higher demand than configurable controls, and is also more difficult to code.


  • 0

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#35 VikingAntics

VikingAntics

    GMC Member

  • GMC Member
  • 217 posts
  • Version:GM:Studio

Posted 19 June 2013 - 12:46 PM

kburkhart84,

 

First, I would like to say that anyone who shares their hard work with the community should be commended for their generosity.  That said, I agree with what you said about the "closed" nature of a gex module.  Unless I misunderstand, we cannot see the source code of a gex, and for me, even if it is the most useful code in the whole forum, rules it out (unless the source code is included with the gex).  The problem with not having the source code is that if you build your game using these wonderful modules, and there is a problem, you are really in a bind.  And as we all know, people tend to come and go with from these forums, so the author may not even be around anymore.  With GM, it is not a problem, because the good people at YoYo will eventually fix bugs or offer workarounds, but with a gex, it really is a black box and too risky without source code.  In my opinion of course. :)

 

Thanks for your contributions!


  • 0

              FF_Viking-Antics_Small.png               ParticleGizmo.png


#36 Slammin Sam

Slammin Sam

    I craft juicy things

  • GMC Member
  • 854 posts
  • Version:GM:Studio

Posted 19 June 2013 - 12:51 PM

I've loved this extension ever since I downloaded it a week ago. Best thing I've ever done for my games. I have heaps of tweens playing at a time, and my game still runs at 600/600 when I activate super fast mode :P It definitely hasn't slowed my game down by a noticeable amount.

 

EDIT: I would recommend EVERYONE download this!


Edited by Slammin Sam, 19 June 2013 - 12:52 PM.

  • 0

Nothing to see here...move along


#37 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 19 June 2013 - 04:40 PM


That said, I agree with what you said about the "closed" nature of a gex module.  Unless I misunderstand, we cannot see the source code of a gex, and for me, even if it is the most useful code in the whole forum, rules it out (unless the source code is included with the gex).  The problem with not having the source code is that if you build your game using these wonderful modules, and there is a problem, you are really in a bind.  And as we all know, people tend to come and go with from these forums, so the author may not even be around anymore.  With GM, it is not a problem, because the good people at YoYo will eventually fix bugs or offer workarounds, but with a gex, it really is a black box and too risky without source code.  In my opinion of course. :)

 

Once the GEX is imported into a project, the source code is accessible via [TweenGMS.gml]. You can find it in the project's extension folder, or right-click the file inside the IDE and select 'Open in Explorer'. Everything is there if you really need to access it. This extension was not made into a GEX to hide stuff, but to simply make it easier for people to import it into their own projects and to give the added benefit of enhanced script auto-completion.

 

I have been using GameMaker for 10 years and have no plans to stop using it or leave the community. I need this extension to stay working for my own needs, so people can be assured that it will be updated, when needed, to reflect changes to GameMaker over time.


Edited by 8BitWarrior, 19 June 2013 - 04:57 PM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#38 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 2026 posts
  • Version:GM:Studio

Posted 19 June 2013 - 05:39 PM

Yes, and the same applies to my kbinput extension, and my vertex animation one that I just released.  It is all gml, and so is accessible the same way.  And I like 8bit intend on being around for a while.  I've seen the same thing with people disappearing, or simply not using GM anymore, but I at least intend on staying for the long haul.  I've been here for 5 years so far :)  In fact, I've stayed around for two reasons.  One is because I saw Yoyo take over and really make improvements to the program, and two, because of the capability to make extensions, and the fact that they ARE being made and are very useful.


  • 1

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#39 VikingAntics

VikingAntics

    GMC Member

  • GMC Member
  • 217 posts
  • Version:GM:Studio

Posted 19 June 2013 - 07:14 PM

Thanks for the clarification on viewing the source code!  Has this always been true?  I don't remember GML being visible in GM8 & GM8.1 gex files, but that could just be my lack of understanding.  Anyway, I am glad it is available.  I think both of your extensions are great and I hope you didn't feel I was putting them down.  Thanks for teaching me something new today! :)


  • 0

              FF_Viking-Antics_Small.png               ParticleGizmo.png


#40 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 19 June 2013 - 07:37 PM

Thanks for the clarification on viewing the source code!  Has this always been true?  I don't remember GML being visible in GM8 & GM8.1 gex files, but that could just be my lack of understanding.  Anyway, I am glad it is available.  I think both of your extensions are great and I hope you didn't feel I was putting them down.  Thanks for teaching me something new today! :)

 

I don't actually know if it has always been possible to view a GEX's GML source file. I didn't start using GEX extensions until I started on this one recently. ;)


Edited by 8BitWarrior, 19 June 2013 - 07:37 PM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#41 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 2026 posts
  • Version:GM:Studio

Posted 19 June 2013 - 07:50 PM

I don't think it was possible before studio, at least not as easily.  GM before studio kept all the files of the projects in a single project file, where studio stores a bunch of separate data files, and the gml from extensions is fully visible as data files.  I'm sure that via some utilities(for decompiling maybe) you could get the source code for gml scripts, and you could reverse engineer dlls, which have to be put in the temp folder(or the game folder) at run-time, but that is beyond the "normal" means.

 

And no, I didn't feel that you(Maverick) putting down our extensions.  And you are perfectly entitled to your opinion, and can of course choose to or not to use any given extension, for whatever reason you feel.  You also give a perfectly valid reason for choosing not to use extensions, as in you are not giving a stupid childish "just because" like we see on the GMC often enough.

 

I'm somewhat in agreement with you as far as having source access before using an extension.  I usually weigh in my decision the importance of the extension for a given project, and the difficulty I would have in replacing that extension with either another one or my own code.  If it a simple extension, and/or if it unlikely to break with updates, I'll likely use it so as not to have to reinvent things.  In fact, this tweenGMS is a perfect example of an extension I would use.  It is simple, I could likely code it myself if it somehow breaks, and it doesn't do anything extreme that could break within an update of GMStudio very easily.  Though I like the Ogre3d extension, and other dll extensions too, I don't use them, not only because they aren't compatible with the various other platforms than windows, but because the interfaces to dlls may change at some point, and because the complexity isn't so easy for me to duplicate, so I don't want to get dependent on it.  In fact, because I want better 3d functionality that fits into my "rules" is why I'm working on the 3d vertex animation and eventually the other 3d extension I have in mind.


  • 0

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#42 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 24 June 2013 - 10:39 PM

The latest update (v0.88b) adds a new ease type:
  * EASE_IN_ELASTIC
  * EASE_OUT_ELASTIC  
  * EASE_IN_OUT_ELASTIC
 

As well, delayed tween timing should now be a tad more consistent. If you rely on precise timing, be aware that delays might be one step different from previous versions. Let me know if this causes any unexpected issues.


  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#43 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 25 June 2013 - 04:00 AM

I have not updated the version number (and will not), but shared_Tweener.object.gmx has just been updated to prevent an unexpected difference between HTML5 and other exports.

If you have already downloaded the latest version, I would suggest downloading v0.88b again and simply updating shared_Tweener. There is no need to update any other files.


Edited by 8BitWarrior, 25 June 2013 - 04:00 AM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#44 Kensai_

Kensai_

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 29 June 2013 - 11:12 PM

A question: Can TweenSystemSetUpdateInterval be set to integer values only? Can it be set to 0.5 for example? If this were the case, would this speed the tweens up?


  • 0

#45 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 30 June 2013 - 03:43 AM

A question: Can TweenSystemSetUpdateInterval be set to integer values only? Can it be set to 0.5 for example? If this were the case, would this speed the tweens up?

 

With TweenSystemSetUpdateInterval(), 1 is the lowest accepted value, which runs the system once every frame/step. In the future, after introducing support for delta time, I may make it possible to use values between 0-1 to speed up the entire system.

 

For now, to speed up a tween, you will need to use TweenSetSpeed() with a specific tween reference. TweenSetSpeed(tween, 2) would double the speed of a tween.

 

Edit:

I might allow for setting values between 0-1 sooner than later. But, I'll need to make sure it doesn't present any unforseen issues. However, setting a value to 0.5 would double the required cpu usage per each step. As long as that is known, it could be fine.

 

TweenSetSpeed(), on the other hand, does NOT affect the required cpu usage.


Edited by 8BitWarrior, 30 June 2013 - 03:52 AM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#46 Kensai_

Kensai_

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 30 June 2013 - 05:03 AM

Thank you for the reply! This will be quite useful.


  • 0

#47 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 01 July 2013 - 01:46 AM

Thank you for the reply! This will be quite useful.

 

In case it wasn't made clear, TweenSetSpeed() can take decimal values, unlike TweenSystemSetUpdateInterval().


  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#48 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 08 July 2013 - 04:32 AM

I have been doing some work on a delegate/callback system which I am looking to merge into TweenGMS.

It allows for multiple scripts+arguments to be added to or removed from a single delegate.

 

Its still quite early and doesn't have any documentation, but you can check out a .gmz example project containing the delegate scripts as well as a basic UIButton object which uses the delegate system.

 

Feel free to use anything from the .gmz in your own projects, or use it as a reference for creating your own delegate/callback system.

By the way, if you notice any callback/delegate conventions to be labeled improperly, feel free to correct me.

 

Delegate System Example:

Spoiler

 

TweenGMS will likely merge with this sytem by implementing the following scripts:

TweenOnFinishAdd()    TweenOnFinishSub()    TweenOnFinishClear()
TweenOnBounceAdd()    TweenOnBounceSub()    TweenOnBounceClear()
TweenOnPauseAdd()     TweenOnPauseSub()     TweenOnPauseClear()
TweenOnResumeAdd()    TweenOnResumeSub()    TweenOnResumeClear()
TweenOnStartAdd()     TweenOnStartSub()     TweenOnStartClear()
TweenOnStopAdd()      TweenOnStopSub()      TweenOnStopClear()

Edited by 8BitWarrior, 01 August 2013 - 02:35 AM.

  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6


#49 Kensai_

Kensai_

    GMC Member

  • GMC Member
  • 24 posts
  • Version:GM:Studio

Posted 11 July 2013 - 07:13 AM

Many thanks! I will check this out later  :)


  • 0

#50 8BitWarrior

8BitWarrior

    GMC Member

  • GMC Member
  • 307 posts
  • Version:GM:Studio

Posted 23 July 2013 - 10:04 PM

There may be some issues with TweenGMS when run with the latest version of GameMaker:Studio. I will be releasing an update today or tomorrow to remedy some potential issues, as well as to add the new event system I have been working on.


  • 0

tgms_footer.png 8BitWarrior.com | @8BitWarrior | Prov:3:5-6