Closed norru closed 8 years ago
There are different ways to address this. One - to keep an enum of PSOs for each target format you want to use. Totally not convenient.
Another - is to use RawRenderTarget
component instead of RenderTarget
. The difference is - type being provided at the run/init time rather than compile time. So you can work with anything the user requests, but the compiler will not protect you.
Not sure I made myself clear. I have found only one public "text.draw" function, and it expect a Rgba8 target as a parameter.
Is there a way to wrap any RenderTarget
to obtain a RenderTargetView<R, gfx::format::Rgba8>
? For instance if I've got a Srgba8
framebuffer?
pub fn draw<C: CommandBuffer<R>>(
&mut self,
encoder: &mut Encoder<R, C>,
target: &RenderTargetView<R, gfx::format::Rgba8>
) -> Result<(), Error> {
self.draw_at(encoder, target, DEFAULT_PROJECTION)
}
pub fn draw_at<C: CommandBuffer<R>>(
&mut self,
encoder: &mut Encoder<R, C>,
target: &RenderTargetView<R, gfx::format::Rgba8>,
proj: [[f32; 4]; 4]
) -> Result<(), Error> {
@kvark: is this gfx_text
project part of gfx
too?
is this gfx_text project part of gfx too?
No, it's separate project that uses gfx API to render text.
target: &RenderTargetView<R, gfx::format::Rgba8>
Seems like function signature should be relaxed. E.g. change it to target: &RenderTargetView<R, F>
and F: Formatted
(if I understand gfx/core/format
correctly). This requires fixes in gfx_text
.
Yes, the interface needs to be changed to support F: Formatted
, and the implementation would need to keep a lazy map of PSO objects for requested formats, using RawRenderTarget
component.
How about parameterizing the format at the factory level? Would it be possible at all?
In Pseudo-Rust (not syntax-complete)
let rgba_text = RendererBuilder::new::<Rgba8>(factory);
let srgba_text = RendererBuilder::new::<Srgba8>(factory);
Then the client could create as many renderers as required according to its render target needs.
@norru sounds good
This makes it impossible to use together with piston_window, since it's framebuffer is hardcoded as an RenderTargetView<Resources, Srgba8>
Is there a workaround for this?
@joelwkall not at the moment, but @norru solution would be compatible with Piston.
I have looked at the solution and it's not as easy as I thought it would be
The first workaround I could think of was to render to a Rgba8 rendertarget containing text and then compose the text target passint it as a source texture to the postprocessing/effects stage.
On 27 June 2016 at 12:19, Dzmitry Malyshau notifications@github.com wrote:
@joelwkall https://github.com/joelwkall not at the moment, but @norru https://github.com/norru solution would be compatible with Piston.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PistonDevelopers/gfx_text/issues/45#issuecomment-228718750, or mute the thread https://github.com/notifications/unsubscribe/AA2Ry9udGB13HfdXyr7zUblMUzAXfkZZks5qP7GtgaJpZM4I0U1z .
Cheers, Nico
@norru please see #47 for what I had in mind
I see what you did there! Thanks!
The approach I was attempting was to macroify both the text_renderer and the pipeline but it was too much hassle.
I haven't had much time to play with Gfx lately, I'll try your change as soon as I get back to it.
Thanks!
On 1 July 2016 at 07:33, Kagami Hiiragi notifications@github.com wrote:
Closed #45 https://github.com/PistonDevelopers/gfx_text/issues/45 via
47 https://github.com/PistonDevelopers/gfx_text/pull/47.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PistonDevelopers/gfx_text/issues/45#event-710107094, or mute the thread https://github.com/notifications/unsubscribe/AA2Ry2SJHKuAN7lPUHXwxgxu3nYxAjfWks5qRLS4gaJpZM4I0U1z .
Cheers, Nico
Hello, I have tried @kvark's change from #47 and works great. I might revisit my approach later but this is not a priority and I'm happy with the update. Thanks!
Neither HDR targets nor Srgba8 target are allowed. Draw is hardcoded on Rgba8.
What's the recommended workaround?