Horde3D

The utility function showFrameStats doesn't take a "layer" argument (it always uses the value of 0).

I'm writing a 2D application at the moment which draws many objects on layer 0. Because the frame-stats are hard-coded to use layer 0, they get covered up by my own objects.

I've fixed this locally by increasing the hard-coded number, but I think a better solution would be to have showFrameStats take layer as a parameter (like all other 2d drawing functions).

That would make sense indeed.

Funnily I was experimenting with showFrameStats yesterday evening to make it look a bit cooler. One thing I experienced is that the current overlay origin at the bottom left corner is quite unintuitive if you want to make (even simple) GUI elements which are usually drawn from top to bottom (e.g. a list). I'm thinking of changing the origin so that it is at the top left corner. Since you are currently writing a 2D app, what do you think?

Another thing that is needed is a color parameter for overlays. This would make it easy to get colored fonts.

Concerning the layer: 0 is certainly no good choice; either we expose it as parameter as you suggest or just put it on the highest layer since it is a debug element which should usually always be on top.

Well, I don't mind it how it currently is... But in my dreams I would like the 2D rendering API to function exactly the same as the 3D one (i.e. a scene-graph of nodes). A regular camera node could set up the 2D frustum, and regular mesh/model nodes could represent the quads. Horde3DUtils could provide functions to generate geometry/etc from quads (and possibly other shapes!).


In my engine, I have actually implemented my own scene-graph on top of Horde3D::showOverlay!
I have Geometry nodes (calls Horde3D::showOverlay), Text nodes (calls Horde3DUtils::showText), group nodes and frustum nodes.
The frustum nodes push and pop 2D frustums on a stack, and the frustum on the top of the stack is used to transform all of the position inputs that are passed to showOverlay/showText.

This way, if I want the origin the be in the top-left corner, then I can just add a frustum node to my 2D scene...

This should just be a material uniform IMO.

Yeah I just chose to put it on the top instead of changing the API because it is only called for one purpose (Debugging).

However, in my engine I don't actually use Horde's layer system at all! All elements are drawn on layer 0 - but I sort them myself so that they are layered properly (I was unable to sort the showFrameStats geometry, because my scene-graph doesn't have a "FrameStatsNode").

I too have been working on text rendering and showframestats. So far I've got variable width fonts using distance fields:




I've been thinking about ripping out the whole overlay layer concept from the engine, and simply let the engine draw the overlays in the order they are added by the calling application... Simple, and more flexible.

@DarkAngel:
Unfortunately the overlay graph has issues with dynamic text rendering where the overlays change a lot. So it would require some special care. I think it is better to handle that in a different layer as you do now. The colors can be handled by material uniforms but that's quite impractical for colored text (especially if it is changing color) and would mean a lot of material resource cloning overhead. So I think an overlay color exposed to the shader as special uniform (as for particles) makes sense.

@Vurlix:
I was also interested in distance fields for font rendering. How is the quality in general for smaller on-screen fonts? Distance field textures seem to have problems with sharp edges and I also see your font looks very cartoonish, as the ones in Team Fortress 2 do.

When I implemented distance-field fonts in the Gamebryo engine (I would post the code, but it belongs to my employer...) the quality was exactly the same as standard (alpha-masked) fonts when rendering at normal scale.
i.e. if a distance-field texture was generated for a 24px sized font, then it would look perfect when rendered at 24px.
It was only when the font was scaled (e.g. rendered at 120px) that the sharp-edges start to appear curved (which is still preferable to alpha-masks, which appear aliased when scaled).

@Vurlix: I can't share the code that I wrote, but I can share my texture-generation algorithms with you if you like.

Here's what a more sharp-edged font (Helvetica) rendered at different sizes from the same 32x32 pixel glyphs, all using the same shader. Straight lines at some angles (like in the W) tend to squiggle a bit, and of course the corners aren't perfectly sharp. The one with the "<" mark is rendered at 1:1 scale.




I might to implement something like in Valve's paper for sharper corners. Still, not bad for glyphs with an actual texture size of 32x32. Other improvements could probably done in the shader.

Some of the edges seem aliased, even at 1:1 scale, which could probably be improved. I would love to contribute to your shader, if you feel like sharing it with the community.