jsprime output does not work on gitraw

[nanjizal]

Hugh

jsprime does not seem to be setup to work with gitraw, perhaps I made a mistake, but all the other toolkits seem to work with gitraw. gitraw is useful so people can see code running without having to build, see NME jsprime link on this experimental repository.

https://github.com/nanjizal/tetrisTriangles/blob/master/README.md

Feel free to close if you don't feel this is important. Very cool to have NME js :)

[hughsando]

Looking at the developer console in chrome, it looking for "/nme/6.058/nme.js" and nme.mem and nmeclasses.js. These files should probably be put in the same directory as index.html and referred to using relative paths in index.html. You could edit the index file, or try setting the filename in build.nmml using:

  <set name="nmeJs" value="Nme.js" />
  <set name="nmeClassesJs" value="NmeClasses.js" />

Then upload all these files.

[nanjizal]

Thanks Hugh will take a look, with the gitraw lots of toolkits are not setup to provide a clean html bin, would be good to have this option since every time check in a user can either delete the whole bin, but if they could publish clean then they would not need to adjust bin. Viewable samples get twitter hits so a raw option that when publishing cleans bin and leaves just minimal would be perhaps worthwhile as it's then very easy to keep minimal bin committed.

By the way what is the fastest way to do triangles each render frame in NME? Getting better performance in other tests and OpenFL seems quite a bit faster, expect drawing api must not be ideal approach, at moment trying to rebuild better hitTest so not updated demos so code is bit broken right now, but the Main class for NME I have not changed it just has some draw commands every frame same as code as OpenFL. Canvas js and WebGL js runs fairly well so it seems strange jsprime is slower - is that expected, I am getting slow on SVG but that's likely my fault and Kha Graphics2 runs well but I am doing something wrong on Kha Graphics4, as that's slow. But NME and OpenFL code are the same just drawing commands rest is my platform independant triangle generation stuff so it seems strange that jsprime seems much slower.

[hughsando]

Not sure what the best source code is, but I got something working. I think the problem is with the number of "lineTo" commands - which involve a js -> webasm conversion, which I'm guessing is expensive. There was a problem with the drawTriangles command, which I have fixed, but this is a better Api. The render routine would look like:

    function renderTriangles(){
        var triangles = Triangle.triangles;
        var n = triangles.length;

        g.clear();
        if (n==0)
           return;

        var verts = new Array<Float>();
        var cols = new Array<Int>();

        verts[6*n-1] = 0.0;
        cols[n*3-1] = 0;
        var idx = 0;
        var cidx = 0;
        for(tri in triangles)
        {
           verts[idx++] = tri.ax;
           verts[idx++] = tri.ay;
           verts[idx++] = tri.bx;
           verts[idx++] = tri.by;
           verts[idx++] = tri.cx;
           verts[idx++] = tri.cy;
           var c = gameColors[ tri.colorID ];
           cols[cidx++] = c;
           cols[cidx++] = c;
           cols[cidx++] = c;
        }
        g.drawTriangles(verts, null, null, null, cols);
    }

But you can take advantages of the NME display list code. Here I have moved the scale/offset to the viewSprite, and setup the scaling to be dynamic, by adding to the constructor:

    ...
       Lib.current.stage.addEventListener( Event.ENTER_FRAME, enterFrame );

        nme.Lib.current.addChild( new nme.display.FPS() );
        Lib.current.stage.addEventListener( Event.RESIZE, function(_) {
           var s = Lib.current.stage;
           var scale =  Math.min( s.stageWidth, s.stageHeight ) *0.4;
           viewSprite.scaleX = viewSprite.scaleY = scale;
           viewSprite.x = scale * 0.1;
           viewSprite.y = scale * 0.1;
        } );

But really is is still doing way too much work in this case. For best speed, I would have 3 display sprites.

• One containing the background triangles which would not change after creation.
• One containing all the fallen blocks - updated after a block hits the ground, or rows are eliminated
• One containing the falling block. Now, you could re-render the falling block each time, or just go "block.y += dy". The "block.y += dy" is in fact the only render code that should be running most frames, and should be super-fast.

This immediate-mode render is not really in the spirit on nme, and it is not something I really want to optimize for, since there are better ways of doing it.

I have also added "-Dflatoutput" to put all the required files in a flat directory.

[nanjizal]

Current version I extended in Kha. https://rawgit.com/nanjizal/tetrisTriangles/master/build/html5/index.html?11 It's ready to get working with other systems I will have a look through your comments tomorrow and integrate it with NME. I did not want to tie the game code to a toolkit as it seemed in webgl, kha and luxe to probably work ok with just triangle implementation, but can I access shaders with NME? I guess I could do scale with the shader? Do you batch the drawTriangles commands, not sure I know how that works, but I think the graphics2 in Kha does that?

[nanjizal]

by the way thanks for taking a look :) About time I got code back working in other toolkits, was not practical to develop it in all at same time. Will start with NME :)

[hughsando]

I had to change the flash-renderer to use "Tetris" not "TetrisTriangles", and add hx3compat haxelib, since I'm using a dev haxe build.

Nme does not batch the triangles if you use lineTo - but it does keep all the triangles together if you use drawTriangles. You can also use the gl api on nme - but really if you are going to do just this, I think you are better off using one of the other frameworks without a display list because this is really nme's strength. An nme-optimized version of this code would probably be based around tiles, rather than triangles, and use layers, most of which would not change, and ultimately the code would look quite different. I appreciate that this is not something you want to do.