Yep don't get me wrong, I'm really happy and grateful that you guys implemented the new low-res scale feature for us. But just in case you're still working at the particulars of it I thought I'd offer a couple of suggestions to expand it a bit further.

1. Toggle linearSampling on/off within the fullscreen scaling rollout. Setting Sampling to Point in configuration settings works during edit-time but we can't toggle it during run-time unfortunately. However I noticed that switching this section in Layout.prototype.drawGL:

          if (render_to_texture)

          {

              ?// Need another canvas to render to. Ensure it is created.

              ?if (!this.runtime.layout_tex)

              ?{

                    this.runtime.layout_tex = glw.createEmptyTexture(this.runtime.draw_width, this.runtime.draw_height, this.runtime.linearSampling);

              ?}

              ?// Window size has changed (browser fullscreen mode)

              ?if (this.runtime.layout_tex.c2width !== this.runtime.draw_width || this.runtime.layout_tex.c2height !== this.runtime.draw_height)

              ?{

                    glw.deleteTexture(this.runtime.layout_tex);

                    this.runtime.layout_tex = glw.createEmptyTexture(this.runtime.draw_width, this.runtime.draw_height, this.runtime.linearSampling);

              ?}

to this:

          if (render_to_texture)

          {

              ?// Need another canvas to render to. Ensure it is created.

              ?if (!this.runtime.layout_tex)

              ?{

                    this.runtime.layout_tex = glw.createEmptyTexture(this.runtime.draw_width, this.runtime.draw_height, this.runtime.pointSampling);

              ?}

              ?// Window size has changed (browser fullscreen mode)

              ?if (this.runtime.layout_tex.c2width !== this.runtime.draw_width || this.runtime.layout_tex.c2height !== this.runtime.draw_height)

              ?{

                    glw.deleteTexture(this.runtime.layout_tex);

                    this.runtime.layout_tex = glw.createEmptyTexture(this.runtime.draw_width, this.runtime.draw_height, this.runtime.pointSampling);

              ?}

... turns off filtering for the upscaled texture in low-quality mode while, at least as far as I can see, retaining the linear sampling effect for high-quality mode. This means the high/low-quality fullscreen scaling could also double as a real-time toggle for linear/point sampling quite easily.

2. Okay I may be the only guy around who's actually interested in this but figured I'd ask anyway :P Sometimes a 2X pre-scale can be useful when you have effects that rely on higher than 1X scale, such as an overlay texture to simulate CRT scanlines in my own case. It could also make linear sampling without pixel rounding look less blurry and still keep much of the speed benefit we get with 1X scale. Just thought I'd mention it.

But in any case, great stuff. Thanks again for the new feature :)

Thanks a lot, very happy about this :)

+1 to Sebastian

I kinda dislike the term art myself. It's so often flung around by people who want to feel extra clever about what they do. I think of art as something that consciously tries to provoke or communicate a feeling, a message, or whatever through non-explicit means. Other people may have other opinions about it. But eh, in the end it doesn't matter one bit whether games can be labelled art or not imo. It's just a word.

Wow! Over two hundred thousand in my case :P Thanks, that worked nicely.

Task manager says:

Processes running -> 2 nw.exe, no game.exe.

Disk usage is hogged by nw.exe reading at about 250 kb/second. svchost.exe also uses quite a bit: 130 kb/s.

No antivirus software installed, just comodo firewall. But the firewall always informs me if it decided to block something it doesn't trust so I don't think that's it.

Link to .capx file (required!):

dl.dropboxusercontent.com/u/70562654/Prototype3.6_340x236_bugreport.capx

Steps to reproduce:

1. Run preview with node-webkit

2.

3.

Observed result:

Harddisk loads like mad but the preview never executes. To stop it I need to kill the nw.exe processes in Task Manager, which also takes a loooong time to complete. This only happens the first time I try to run preview, on subsequent runs preview only takes about a couple of seconds to get going. Closing and re-opening C2 makes no difference; if I've already run Node-webkit preview once after a fresh boot it will always run without problems. Also doesn't happen with exported Node-webkit.

Expected result:

Browsers affected:

Chrome: no

Firefox: ?

Internet Explorer: ?

Operating system & service pack:

Windows 7 64-bit. Service pack 1

Construct 2 version:

r152    

This started to happen around r142-r143 I think? Definitely sometime between r139 and r146. It doesn't seem to happen with new capx'es.

ith the new 2D features in Unity, it will be impossible to beat it for functionality, but for getting things done quickly, C2 is pretty cool.

Could be. But Unity's price tag is brutal. And the free version is pretty crippled/useless imo.

Sure it's not a problem with your Ubuntu installation/hardware setup? I've never known Scirra to fling falsehoods around to make a quick buck before :P

As for Node-Webkit deployment in Win, Windows 7 and XP have always run em problem-free here.

Thanks a heap for these pointers! :) It looks like my fumblings with webgl were pretty redundant. It's just as well! :P

Point sampling: For WebGL this seems pretty trivial, just change the flag from linearsampling to pointsampling for the rendertexture. I have no idea about canvas2d (yet) though. I've been wanting this mostly to prevent undue slowdowns in Webgl rendering and like you said, the added overhead of scaling another canvas might nullify any performance gains with canvas2d. I'll give it a try though, it should help with the sub-pixel rendering issue at least.

In the meantime, thanks again :)

EDIT: Seems that in order to account for applied shader effects I'll need to look into renderEffectchain() as well. Will do so when I have more time.

Webgl is turning out to be a real horror show. How do humans work with this? Ahh.. :P

Anyway, I am trying to start simple and create a 4-vertex quad to display on screen at the bottom of the drawgl() function. I've managed to create a buffer for the vertices in InitState and bind it to the arraybuffer. So far so good I guess. When I try to draw the thing though, I get an error message about the shaderProgram not being defined. This shaderprogram seems to be specific to C2 so I can't dig up any solution on the internet. How do I define this? The DrawGL() snippet looks like this:

          gl.bindBuffer(gl.ARRAY_BUFFER, squareVertexPositionBuffer);

              gl.vertexAttribPointer(shaderProgram.vertexPositionAttribute, squareVertexPositionBuffer.itemSize, gl.FLOAT, false, 0, 0);

//          mat4.translate(matmv, [3.0, 0.0, 0.0]);

          gl.drawArrays(gl.TRIANGLE_STRIP, 0, squareVertexPositionBuffer.numItems);

EDIT: Ah, nevermind. Figured it out.

EDIT2: Right, this is what I have in DrawGL right now. It runs fine but I see no quad.

          var shaderProgram = gl.createProgram();

          gl.bindBuffer(gl.ARRAY_BUFFER, squareVertexPositionBuffer);

          mat4.translate(gl.matMV, [3.0, 0.0, 0.0]);

              gl.vertexAttribPointer(shaderProgram.vertexPositionAttribute, squareVertexPositionBuffer.itemSize, gl.FLOAT, false, 0, 0);

          gl.uniformMatrix4fv(shaderProgram.locMatP, false, gl.matP);

              gl.uniformMatrix4fv(shaderProgram.locMatMV, false, gl.matMV);

          gl.drawArrays(gl.TRIANGLE_STRIP, 0, squareVertexPositionBuffer.numItems);

edited><editID>ErekT</editID><editDate>2013-10-13 18:55:14</editDate></edited>

Thanks, that's a big help :)

Okay, I'm deep into the guts of glwrap.js tinkering about to figure out how it all works. My hope is that I'll be able to understand it well enough to change the rendering pipeline around a bit to allow for all rendering to take place before the viewport gets scaled up. Which is probably waaay over my head but what the heck, I'll try anyway. The main thing I'm puzzled about is the sequential order of it all. Is there even a fixed order to the rendering pipeline? The closest thing I found was SwitchProgram and InitState which only gets run once. But that tells me little about at what point in the render loop methods like SetSize and Scale get called. Also not sure what kind of numbers get passed to indicate width and height for the viewport and whatnot. I assumed at first that these were the same as either window size width and height or system resolution width and height, but when I tried to change them around I got weird scaling results and graphical artifacts.

Just so you know, I don't plan to release a modified glwrap.js or anything. If I get it to work I'll try to put it into a separate plugin. For now tho, I'm just trying to understand.