Wc3C.net

Wc3C.net (http://www.wc3c.net/forums.php)
-   - Submit a resource - (http://www.wc3c.net/forumdisplay.php?f=637)
-   -   Cinema Workshop (http://www.wc3c.net/showthread.php?t=110341)

Anitarf 07-02-2011 11:39 AM

Cinema Workshop
 
2 Attachment(s)
Attachment 50357


Requirements:
ARGB
Table
LinkedList
TimerUtils
UnitAppearanceTracker
DisplayCenteredText
CINEMA WORKSHOP


This is a compilation of vJass libraries intended to replace the old Cinematic System, which is over five years old already. This compilation itself has been in the making for two years now and represents a major leap forward in terms of speed, functionality and user-friendliness.


Like its predecessor, Cinema Workshop consists of three main components:
  • Transition - A library that facilitates gradual changes of various properties such as unit position.
    Additional modules:



    • UnitTransition



    • UnitColorTransition
    • UnitScaleTransition
    • UnitFacingTransition
    • UnitPositionTransition
    • UnitWalk
    • TerrainFog


  • CineCam - A library that takes command of the game camera and gives the user more control over it.

  • CineScript - The core of the system, a powerful library for composing and playing sequences of events.
    Additional modules:


    • UnitAnimationCineScript
    • UnitTransitionCineScript
    • EnvironmentCineScript
    • UtilityCineScript
    • EffectCineScript
    • SoundCineScript
    • CameraCineScript
    • SubtitleCineScript


The new design is completely modular, each component can be used independently from the other two. Transition and CineScript each come with a collection of extensions that can be included in your map as needed. When used for their primary purpose of making cinematics, the three otherwise independent components achieve a strong synergy. The demo map includes both a sample cinematic that uses the entire CinemaWorkshop as well as a sample code for a triggered spell that only uses CineScript.

Expand Transition library:
Expand CineCam library:
Expand CineScript library:

iNfraNe 07-02-2011 12:14 PM

Finally! This is amazing Ani!

Bribe 07-02-2011 07:29 PM

Nice to see the this cinematic system finally converted into vJass. I don't see the previous "gc()" calls which, in itself, is a huge change for the better.

The local real array in the CineCam library could be turned into something more efficient, like a global array or a series of individual, properly named variables, due to the huge overhead of local arrays.

I hope that this sees some good public usage.

Anitarf 07-02-2011 09:39 PM

Quote:

Originally Posted by Bribe
Nice to see the this cinematic system finally converted into vJass.

CineCam is the only library that I would call a mere conversion. Transition, while still functioning similarly to the old particle subsystem, is so much more general, functional and modular that it really is more of a replacement for, rather than an evolution of, its predecessor. CineScript goes even further, accomplishing things that weren't remotely possible with the old system - see for yourself, try pressing escape while the sample cinematic is playing. ;)

Don't get this the wrong way, I know you didn't mean to say that this was "just a port", I just wanted to point out anyway that considerable improvements have been made beyond the obvious "it's in vJass now", since the first post doesn't mention that beyond the initial description.

Quote:

The local real array in the CineCam library could be turned into something more efficient, like a global array or a series of individual, properly named variables, due to the huge overhead of local arrays.
Well, it has to be an array since I can't use individual variables in a loop. If there is such a big difference between local and global arrays, I could make it global. In the cases where I can replace it with locals, I wonder if declaring those local variables wouldn't be more of an overhead than using an already declared array, especially if I switch to a global one. Were any benchmarks ever done to indicate how many uses of an array justifies a local declaration?

Quote:

I hope that this sees some good public usage.
Is there anyone left making cinematics at all? Even I don't know if I'll be using this for anything beyond the sample cinematic I made for it. Well, I did use CineScript when making my action map and it was incredibly useful there, so I want to point out again that these libraries needn't always be used in tandem, there's plenty of situations where they can be applied individually.

BBQ 07-02-2011 10:41 PM

Quote:

Originally Posted by Anitarf
Well, it has to be an array since I can't use individual variables in a loop. If there is such a big difference between local and global arrays, I could make it global.

As far as I know, when using a local array, 32 kilobytes of memory (4 bytes per array slot, 8192 slots) would be allocated each time the function starts, and deallocated when the function returns. In the case of a global array, 32 kilobytes of memory would be allocated upon map initialization, and never deallocated.

But local variables are quite faster than globals, so I think that the use of a local array is absolutely justified, at least in this case.

Perhaps you could use a linked list (similar to the one in grim001's ListModule) instead of an array when looping through the struct instances in the Transition library.

This should most definitely see some good usage, although WC3 modding is slowly dying.

Captain Griffen 07-03-2011 10:01 PM

Quote:

But local variables are quite faster than globals, so I think that the use of a local array is absolutely justified, at least in this case.

Citation needed. My testing I seem to recall showed no discernible difference in speed.

BBQ 07-03-2011 10:14 PM

Quote:

Originally Posted by Captain Griffen
Citation needed. My testing I seem to recall showed no discernible difference in speed.

I can't provide you with any citations, but I am very sure that the speed at which variables can be accessed depends on how many variables are there in the scope.

And you know it yourself that vJass can generate hundreds of globals, which in turn makes them slower.

Captain Griffen 07-03-2011 11:11 PM

Quote:

I can't provide you with any citations, but I am very sure that the speed at which variables can be accessed depends on how many variables are there in the scope.

Why would you be very sure of that? Consider that we aren't just dealing with a VM, we're dealing with a Blizzard VM.

Anitarf 07-04-2011 12:38 PM

Quote:

Originally Posted by Captain Griffen
Why would you be very sure of that? Consider that we aren't just dealing with a VM, we're dealing with a Blizzard VM.

We'd need to test this in a map where you can easily switch between having no and a few hundred declared variables/arrays (by the use of nested textmacros) and then do a hundred get/set operations (again with textmacros, no loops) and test how long that takes depending on the number of global variables in the map and depending on whether the get/set operations are being done on a global or a local, so four test cases in total. Someone with a working japi would need to do this since I don't trust fps tests with something as fast as variable operations, but this is really a subject for a new thread.

Quote:

Originally Posted by BBQ
As far as I know, when using a local array, 32 kilobytes of memory (4 bytes per array slot, 8192 slots) would be allocated each time the function starts, and deallocated when the function returns. In the case of a global array, 32 kilobytes of memory would be allocated upon map initialization, and never deallocated.

It was my understanding that arrays were allocated incrementally as needed, but maybe I misunderstood what this post says. In either case, if local variables are indeed faster than globals when there are many globals in the map then this is a moot point as the amount of operations I do on the local array should out-weight the cost of its allocation.

Quote:

Originally Posted by BBQ
Perhaps you could use a linked list (similar to the one in grim001's ListModule) instead of an array when looping through the struct instances in the Transition library.

I could do that, but the speed gain would be insignificant. If I was having performance issues with Transition, the first thing I would do would be to rewrite UnitPositionTransition, since that one is likely to see the most use and its onTransition method is uninlineable, so I would copy&paste the Transition code into it instead of implementing the module so that I could inline the onTransition method manually. If I were to go this far, then it would make sense to also use grim001's module, but considering how ugly this solution is I would rather not go this far unless I need to.

BBQ 07-04-2011 02:35 PM

Quote:

Originally Posted by Captain Griffen
Why would you be very sure of that? Consider that we aren't just dealing with a VM, we're dealing with a Blizzard VM.

Okay, here's a post by grim001 that I stumbled upon:
"I once had the idea that it would be better to use only global vars in my engine in order to avoid repeatedly initializing locals. The result is that the whole engine ran about 20% slower.

According to Pipedream the speed of variable access depends on how many other vars there are in that scope. vJASS maps can create thousands of global vars for structs, so globals have a very long list to sort through, whereas locals typically only have a few.

So basically, whichever you have fewer of (locals or globals) should be faster, but you will always have more globals than locals unless you are a freak."
Perhaps you trust him more than you trust me.

Quote:

Originally Posted by Anitarf
We'd need to test this in a map where you can easily switch between having no and a few hundred declared variables/arrays (by the use of nested textmacros) and then do a hundred get/set operations (again with textmacros, no loops) and test how long that takes depending on the number of global variables in the map and depending on whether the get/set operations are being done on a global or a local, so four test cases in total. Someone with a working japi would need to do this since I don't trust fps tests with something as fast as variable operations, but this is really a subject for a new thread.

Unfortunately, textmacros cannot be nested.

Quote:

Originally Posted by Anitarf
It was my understanding that arrays were allocated incrementally as needed, but maybe I misunderstood what this post says. In either case, if local variables are indeed faster than globals when there are many globals in the map then this is a moot point as the amount of operations I do on the local array should out-weight the cost of its allocation.

While the thread you linked to is very awesome (thanks!), it doesn't seem to show whether the memory is allocated incrementally or not.

But anyway, here's a post by weaaddar:
"An array in jass will always use 8192 elements. No matter if your only using 1 or 400. Its very bad to use arrays that you do not need to use. As each type in war3 uses a 4kb integer as its pointer. So you are using roughly 32kb of ram per array. Sure it doesn't seem like much but remember that types also have there own memory usage on the handling stack."

BlackRose 07-06-2011 11:25 AM

Amazing sample cinematic, I crave more.

PurgeandFire111 07-10-2011 04:00 AM

Awesome! I was always waiting for vJASS cine libs. I'll definitely check this out.

TotallyAwesome 08-18-2011 09:04 PM

Wow, this is a really incredible system, wish I had noticed this earlier! Learning to use it now, I first thought of using your old system, but was put off by a lot of outdated stuff (which, still, worked really well in practice).

BlackRose 01-29-2014 12:28 PM

Reupload map?

Anitarf 01-29-2014 04:09 PM

Quote:

Originally Posted by BlackRose
Reupload map?

Ah, I didn't realize the download link was broken from the downtime. Should be fixed now.

I have some further updates planned for this, at the moment I am waiting to see if I'll be able to convince Vex to add a feature I'd like to use to JassHelper.


All times are GMT. The time now is 04:49 AM.

Powered by vBulletin (Copyright ©2000 - 2019, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services