saiyadjin's Forum Posts

  • i've noticed another "bug", while c2runtime.js is being created, i'll have to display that in images. but first things first - here's all JS's cleaned in exporters/html folder.

    tested on my big project, works ok.

    here's the DL:

    https://dl.dropboxusercontent.com/u/136 ... rFiles.rar

    still though i've tried exporting empty project and i noticed there is still some problems and i've found out which ones:

    if you open c2runtime.js and find this line (1485):

    RenderCell_.prototype.isEmpty = function ()
    	{
    		if (!this.objects.length)
    		{
    ;
    ;
    			return true;
    		}
    		if (this.objects.length > this.pending_removal.count())
    			return false;
    ;
    		this.flush_pending();		// takes fast path and just resets state
    		return true;
    	};[/code:38s3eehs]
    
    as you can notice there are some ";" appearing randomly inside that code which is very very wierd. it happens because the following code which is found in common_prelude.js has some "assert2" statements that are on export translated to ";" instead to empty space:
    
    [code:38s3eehs]RenderCell_.prototype.isEmpty = function ()
    	{
    		// 'Empty' state is a little non-trivial since there is the set of objects pending_removal
    		// to take in to consideration. First of all if objects is empty then we know the cell is empty.
    		if (!this.objects.length)
    		{
    			assert2(this.pending_removal.isEmpty(), "expected empty pending removal list");
    			assert2(!this.any_pending_removal, "expected no pending removal state");
    			return true;
    		}
    		
    		// 'objects' is not empty. However if there are fewer instances in the removal queue, then
    		// even if we called flush_pending we know there would still be instances left.
    		// So we can safely indicate that the cell is not empty.
    		if (this.objects.length > this.pending_removal.count())
    			return false;
    		
    		// Otherwise every item in objects must be in the pending removal set.
    		// The set will be empty if we update it. Use this opportunity to clear the state
    		// and indicate empty.
    		assert2(this.objects.length === this.pending_removal.count(), "expected pending queue to be same size as object list");
    		this.flush_pending();		// takes fast path and just resets state
    		return true;
    	};[/code:38s3eehs]
    
    as you all know, to minimize size, comments are removed, and assert2  statements are removed, which leave a semicolon in their place for no obvious reason. since this happens in runtime while exporting i can't fix that one, this one is on Ashley <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">
  • i agree with blackhornet. seems like the easiest way to control what each instance does.

  • glerikud - i will keep this post updated with everything i do, so stay tuned.

    R0J0hound - true. but some users report that some stuff doesn't work when minimized from c2. therefore those might get fixed.

  • i don't see why following conventions that were written by JSLint and other JS developers shouldn't be followed. even a small semicolon missing can cause errors in execution of code, same as badly written code. i've just used the tool to fix the few missing errors in each JS file you provide.

    if you really don't trust me, just check how much "fight" did they have about one single semicolon on bootstrap, and in the end both jQuery and bootstrap fix'd the error - https://github.com/twbs/bootstrap/issues/3057

    also like i said, i'll post (today or tommorow) cleaned the rest of files, and then i will go do some microoptimizations (maybe i find even some larger ones, we'll see), just don't come then saying "but this small optimization doesn't mean much, so we won't implement it", because in tight performing systems like game engines, each optimization is a bless.

  • maybe, not sure that there is a performance improvement, but following these fixes that JSLint provides makes code more "stable" and less prone to errors. also minification works better when it's clean.

    i was checking code for performance improvements and i'll do that next once i finish this "cleanup". i've spotted some functions and stuff that can be improved, possibly only in microbenchmarks, but lots of micro ~ 1 macro

    i noticed that some statements don't end with ";" for example, which makes compiler compile 2 times the same statement because JS compilers "try" to parse the same thing with / without ";", so if it's missing it's doing a double job. (at least according to guys on stack overflow). still some functions that are long one liners (saw these a lot) and end up with })})})}) are better written }); }); }); just because it provides more stability when compiling and reducing errors.

  • here, i've cleaned the plugins with JSLint (runtime and editme). tested on 3-4 projects and my huge one, everything seems to work normally, didn't have errors before, don't have them now, still might help with minimizing / compiling errors.

    Ashley

    https://dl.dropboxusercontent.com/u/136 ... lugins.rar

    i'll go and finish with JS files in c2/exporters/html

  • nope. c2runtime is just a "engine file" which is made out of some js files that can be found in html/exporters.

    data.js is a helper file which contains mostly your logic that you made up with events, variables and more.

    together they work as an engine.

    your sounds / images and the rest is contained in other folders on export.

  • mostly i agree, but compilers / interpreters have to handle javascript errors when they are caught and losing time to handling them just to avoid errors takes some small amount of time. when it gets loaded with such small time errors - all together it causes a bit more of time wasted.

    nontheless i'll do my job and clean the rest of the files on the current version of C2 and upload them here. you can still check them and use if you want, if you don't want won't bother me, i'm just trying to help you out guys <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    anyway this analyzer does the following: CoffeeLint, ESLint, CSSLint, TSLint.

    more details here: https://visualstudiogallery.msdn.micros ... 820d79be1d

  • you should really update your IOS to newer versions it will work way faster. not sure though which iphone supports which IOS since i don't have one <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    just found it out:

    http://iossupportmatrix.com/

    it would seem that iphone 4S and newer only support latest IOS, and iphone 4 can have 7.1.2. as latest which has a really slow webview.

  • interesting, it used to be free like a couple of months ago, didn't know they changed that.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • hey

    Ashley - i've cleaned all the behaviours with Web Analyzer and will leave clean versions on my dropbox, download file is here:

    https://dl.dropboxusercontent.com/u/136 ... thLint.rar

    i've also replaced them in html/exporters, ran a project and everything seems to be smooth, no errors, no bugs, seems to be okay.

    i'll go clean plugins next. and then the JS files in html5/exporters

  • interesting, might be beause edge has a better JS engine currently (the best by performance at least as i've read online)

  • ofcourse bad logic can lead to bad performance. maybe not as much in events as much in the underlying engine, but you can do it with logic too.

    the hardest part is determining what slows down your game, but that's why we have debugger

  • another thing to notice (for semicolons) .

    http://www.bradoncode.com/blog/2015/08/ ... insertion/

    it would seem that a lot of things are processed if there is a missing semicolon, valid tokens get immidiately to read the next one, but the ones missing seem to do a bit of overhead. (check image "putting it all together")

  • because inspect tab checks for loads of variables that have to be refreshed each tick, therefore the slowdown doesn't happen because of number of objects / what you did on the scene, but because debugger has to update lots of values.

    it's a good thing that you can add to watch variables that only you are interested into, and change tab, which then shows the real performance. ofcourse if you watch too many vars you can get the same slowdown on watch tab too i think best to check fps/cpu/etc is to create your own ingame debugger and debug with it, turnable by some letter / variable