-
Notifications
You must be signed in to change notification settings - Fork 549
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Texture binding + creation #112
Conversation
This way, it won't be output to `examples/main` but rather `examples/triangle`.
Note that this is only device support. Still need to support it in the renderer, I think? Possibly just need to add a simple loop in |
Also, still needs to handle the case of sampler objects not being supported. |
} | ||
} | ||
|
||
fn miplevel1(w: u16) -> u8 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't it be mip_level
?
So how exactly this is going to work if the backend doesn't support sampler objects? |
the most recently seen name") | ||
} else { | ||
for _ in range(0, fill) { | ||
self.texture_info.push(unsafe { ::std::mem::zeroed() }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsafe for performance reasons? I'd rather just have TextureInfo::new()
here, since it's clearer and not a critical hotspot.
Another concern is that I'm not saying one way or another is better, but I'd like us to discuss this and come up with a consistent solution (guidelines, perhaps?). |
@kvark the only reason I store the |
Can we make the target a part of the handle itself then? Regards,
|
We could, but it will double the size of the handle due to alignment. Do you see any big advantage of putting it in the handle instead of storing it inside the backend? |
(Keep in mind that only GL needs this, afaik) |
/// ingrained by many years of public use of inaccurate terminology. | ||
#[deriving(Eq, Ord, PartialEq, PartialOrd, Hash, Clone, Show)] | ||
pub enum FilterMethod { | ||
/// The dumbest filtering possible, nearest-neighbor interpolation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we could even add example images here in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole world would be better off if we added images in https://en.wikipedia.org/wiki/Texture_filtering instead 😈
If tartget is really the only thing out there that the device should track - then yes, I'd rather have it in the handle, which will anyway be an associated type at some point. @bjz?
|
TextureCube, | ||
/// A volume texture, with each 2D layer arranged contiguously. | ||
Texture3D | ||
// TODO: Multisampling? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
😋 thanks! |
112: Correctness fixes from 0.2, plus a lot of goodies r=kvark a=kvark These are changes from gfx-rs#110 back-ported to master. Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
Closes #49