Resize independent fragment shader?

[dbalsom]

I am trying to implement a shader which is dependent on the horizontal resolution of the pixel buffer. It expects 640 pixels or it doesn't work right. If I set my window to 640x400 everything is fine, but the fragment shader gives incorrect results as soon as the window is resized, even if the window hasn't been resized far enough that the pixel buffer has been scaled up.

I suppose this is more of a question than a bug report. How can I run a fragment shader that operates just on the logical pixel buffer and not the viewport window size?

[parasyte]

I suppose this is more of a question than a bug report.

No problem! We have discussions for these kinds of questions!

How can I run a fragment shader that operates just on the logical pixel buffer and not the viewport window size?

The order you call the renderers in pixels.render_with() matters. If you call your renderer first, then it receives the pre-scaled texture. If you call it after the default scaling renderer then it receives the scaled texture. You probably want to call your renderer first, then pass its output to the scaling renderer.

[dbalsom]

Thanks for the quick reply -

I see what you're saying. I might humbly suggest changing the shader example to apply the shader before the scaler, as I assume that's what most people doing pixel games will want to do.

[dbalsom]

I'm at a loss for how to render my shader first as a wgpu neophyte. In the current example, the texture view is drawn by the scaling renderer, so the shader has pixel data to work with. If I draw my shader first, where do I get this pixel data?

[parasyte]

If I draw my shader first, where do I get this pixel data?

You can get a reference to the unscaled texture through pixels.texture() or context.texture. From this reference, you can create a TextureView. That's the texture view that you should be using in your bind group (instead of creating a new texture). This will work for a shader to operate on the unscaled texture, but you still need to scale it correctly to fit the surface size. If you just draw directly to the render target without considering the scale, it will stretch to fill the entire surface.

Usually the scaling renderer will do the scaling correctly, but it's hardcoded to use that same unscaled texture reference as its own input. That texture cannot be used as a render target and the only way to update it is by copying the pixel buffer data to it. I'm not currently sure what the API would look like if the input texture was made configurable at runtime. It could get messy with bind group updates and defaults.

[dbalsom]

I see, thanks. I see the behavior you describe, if i call scaling_renderer.render() it does ignore my shader output.

I would gently argue that an API to provide an input texture to the scaler would be worth considering. A shader that operates on the pixel buffer is likely far more useful to most desired use-cases than a shader that operates on the whole viewport. The pixel buffer is essentially the "screen" of a game or emulator, so without that screen space effects aren't possible, at least not without giving up the integer scaling support.

It just so happens I need non-integer scaling for my emulator, so I may be rolling my own scaler regardless. Just a thought.

[wiz21b]

To add an example, I'm currently trying to make an PAL/NTSC filter for my emulator. That fileter translate a binary video signal into colours (it's an Apple 2 emulator). That kind of operation must be done at the pixel buffer level, not at the screen level. I have not yet started (just spent an hour trying to understand how wgpu/pixels do their job) but my initial feeling is that I'll probably try to make the default scaling shader to accept an arbitrary texture. My idea is that I my do with a simple predefined pipeline:

• apply a shader to transform a pixel buffer into a RGB texture (my NTSC stage)
• apply a scaling buffer to, well, scale
• apply a last shader to add additional post processing

There are 2 points here:

• I guess that pipeline is "enough" to support many needs and doesn't require a complex architecture (although, of course, a flexible archictecture as proposed by parasyte in another issue would definitely be more flexible)
• It retains the scaling buffer which is quite intimidating for a newcomer like me (projection matrix !)
• so, I guess as a newcomer, one can understand the WGSL easily but the WGPU setup is super complex. If I used pixels in the first place it's because it hides complexity, so it'd be nice to retain that property somehow. In this case, by hardcoding the texture layout (which I admit is uper specific to my own experience)

[parasyte]

Thanks for providing feedback and some details of your use case. This is definitely something I intend to improve. Recently #316 was opened to explore what an API could look like that has more capabilities. (This might be the same thread you mentioned.)

I agree that pixels does a good job at abstracting some of the wgpu complexities. (It's actually not that complex for 2D, especially if you have some experience with OpenGL or WebGL. And the boilerplate to get a triangle on screen is like 10x less code than Vulkan, so there's also that metric.)

The abstraction is one of the strengths of pixels because that is what it was designed to do. In any new API, even with more flexibility, I want it to retain that property. It should be easy to use right away without needing to care about most of the details in the underlying GPU layers.