-
Notifications
You must be signed in to change notification settings - Fork 77
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
Font rendering fails to draw characters on screen #607
Comments
I see now that the published 0.4.0-alpha0.3 is not current with master. But still not sure what is intended here. I do realize "alpha" means "not ready" so if filing these issues is annoying instead of helpful I can close it. I'm excited about 0.4! |
the lifecycle vs input has to do with #604 In short: the name changed because input is a better fit |
@rodya-mirov Definitely file any issues you run into, even if you're not sure if the problem is on your end or the project's. In this case, there has been a breaking change since the last release. I'll make a new release soon to correct this. The equivalent for |
Great, thank you! By the way -- I was working from the roguelike tutorial you linked in the docs, as a starting place (code only works in 0.3). In the old way it was clear how to use a Font to render to an image, which is nice if you need to redraw it frequently. But there doesn't seem to be a way to do that with the new API. Did I miss something? |
In the 0.4 way you can render text to a texture using Graphics::set_surface(). You can also get every glyph (together with where they should go, how big they are, etc,etc) using FontRenderer:layout_glyphs. However, as you ask specifically about that being nice for when you need to redraw it a lot of times. If I understand the current system correctly, then this caching is already done for you. From the docs
|
@lenscas I'm looking through the docs for At the moment I'm writing a bunch of text to an image then slicing it up into subimages so I can get an image for each character (basically a quick-and-dirty tileset). At this point it's probably simpler to just make a proper tileset (but, bleh). Edit: I came up with this. I still feel like I'm holding it wrong. Is this the intended use of the APIs?
|
You're essentially doing what the Font API now does for you. If you render the string "Hello world!", a texture on the GPU is updated to contain "Helowrd!" Each However, you are holding the Surface API right in this example. |
Okay -- but would there be a way to use the Font API to render to a surface? |
Rendering to a Surface is the same as rendering to a Graphics instance; your code above works, but isn't needed if you're just worried about performance. |
Right. I'm starting to understand. I have a new problem -- this may actually be a bug with the font renderer. I have a font (mononoki) which worked well with the 0.3 branch. When I attempt the This appears to be a real issue -- if I just attempt to render the text directly with the font, it still comes up as nothing. The only way I can tell the render is even being attempted is that the tiny image above really is being created (and if I gfx.clear it to a different color before flushing, I can see that color). So it does look like the font rendering is doing something wrong with the height (the width looks plausible). |
Hm. Is this font open-source (e.g. can you link to a TTF I can try?) |
I'm guessing it is https://madmalik.github.io/mononoki/ |
It is, yes. I don't have laptop access handy at the moment but the case with Square (where the height came out to be zero) was even more egregious and so may be easier to debug. It was also linked in the roguelike tutorial that your docs link. |
Text issue
Right. I'm starting to understand.
I have a new problem -- this may actually be a bug with the font renderer.
I have a font (mononoki) which worked well with the 0.3 branch. When I attempt the layout_glyphs function on the string "Hello, Quicksilver", with font size 72, the returned vector is (643,16). 16 here is much too small; it looks like this is returning the amount of whitespace above the text (???). If I try it with another font (square) it works even worse -- the returned height is 0. This returned value is the same as if I use draw.
This appears to be a real issue -- if I just attempt to render the text directly with the font, it still comes up as nothing. The only way I can tell the render is even being attempted is that the tiny image above really is being created (and if I gfx.clear it to a different color before flushing, I can see that color). So it does look like the font rendering is doing something wrong with the height (the width looks plausible).
Original issue
Describe the bug
I'm looking at the 0.4 branch, basically because it looks great and because working with lots of
Asset
in the 0.3 branch is ... rough. Not a fan.But look at https://github.com/ryanisaacg/quicksilver/blob/master/examples/07_text.rs
If you use
quicksilver = "0.4.0-alpha0.3"
in Cargo.toml, you'll see that doesn't compile. Most of the imports can be fixed (although how did this even happen?);Settings
is underlifecycle
, and so on.prelude
seems to be gone completely, which is rough.But the real killer is that the examples show you moving the plot along by doing
while let Some(foo) = input.next_event().await { /* stuff */ }
.This looks like a great API; however, there is no
Input
type anywhere in the docs that I can find!To Reproduce
Steps: pull latest cargo branch, copy paste example, hit compile
Expected: code compiles
Actual: code does not compile
Environment and versions (please complete the following information):
The text was updated successfully, but these errors were encountered: