parasyte / parasyte/pixels

How to make the pixel buffer larger than the window

Open
#319 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

question
Dominant language
Rust
Stars
2.1k
Forks
147
Avg merge
12m
Merged PRs (30d)
1

Description

Hello,

I've been using pixels for a while now and I'm now stuck at some edge case. Basically, I'd like to put a bit more information in the pixels buffer than what will be actually drawn. This ends up with my "buffer" being 1 pixel wider than the actual window's width. In the documentation of the SurfaceTexture, it is written : "It is recommended (but not required) that the width and height are equivalent to the physical dimensions of the surface.". But that's not 100% clear to me what happens behind the scenes. Of course I have tried to make a surface texture wider than the actual window size but this brings a white picture (I was expecting a distorted picture, maybe zoomed). I thought that maybe the scaling matrix was at fault, esp. the constraint over the scale factor, so I set it to one. But that didn't succeed...

If you could just tell me where I should start looking that would be very kind. I've also looked in other places in the code and saw there was a "render texture" and a "backing texture" but I fail to understand the difference.

Thank your for your time...

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names SurfaceTexture, the scaling matrix, render texture, and backing texture, but no repository file or test. Start by tracing how SurfaceTexture dimensions are handled and how the render and backing textures relate; done means the supported behavior for a buffer wider than the window is documented or verifiably working.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
computer-graphics
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.