Regarding that 4-vertex upload: Keep in mind that's 4 vertices per image every single frame. In Galileo's case, I can optimize away some of the matrix uploads (the projection matrix rarely changes, e.g.), but you're always going to have to pay for those 4 vertices of a transformBlit.
See also https://github.com/fatcerberus/minisphere/issues/184#issuecomment-313927121
@Rhuan: With my experimental changes to avoid render target changes I managed to get the Galileo mode 0 to run faster (200 FPS) than the Sv1 mode (160 FPS). Modes 1 and 2 are still slower and I can't figure out why (100 FPS).
foo.matrix[1][0] = 3 * (Math.sin(rings[i].t * Math.PI/45) - Math.cos(rings[i].t * Math.PI/45)) / 8;foo.matrix[1][1] = 0.5 - Math.sin(rings[i].t * Math.PI/45) - Math.cos(rings[i].t * Math.PI/45);foo.matrix[1][2] = 3 * Math.cos(rings[i].t * Math.PI/45);//...a few lines laterfoo.translate(0, 50 * Math.cos(rings[i].t * Math.PI/100));
edit: As for that test code, I get about 195 FPS for mode 0 when running under SSJ, and ~215 FPS for the non-debug engine. That's a good sign: It means rendering performance is good enough now that JS execution is starting to become the bottleneck instead. I still get no output though. I thought maybe that might be something to do with my graphics driver, so I tested it on my laptop with its Core i7 iGPU and... same thing. Modes 0 and 1 produce no output, only modes 2 and 3 show any rings.
var ringtex = output.toTexture();while(true) { require('prim').blit(screen, 0, 0, ringtex); screen.flip();}
const Prim = require('prim');var s = new Surface(100, 100);Prim.drawPoint(s, 0, 0, Color.Red);var i = s.toTexture();while (true) { Prim.blit(screen, 5, 5, i); screen.flip();}
I have a feeling there might be a bug with the shader management because Allegro tracks them per-bitmap whereas my code tracks the current shader globally.