next »

[ferreiradaselva]

My library for window creation (SWFW) has *almost* complete support for Wayland and X11, and the work on Windows is progressing, thanks to VirtualBox. I discovered that you can simulate multiple monitors on VirtualBox, which helps to make tests.

Also, thinking about start a Patreon and Liberapay so, maybe, people want to support my open-source projects.

[oahda]

You might remember I was having issues with combining diacritics using Pango for text rendering...

Since I'm still set on having good international text support in my game engine, I decided to see what else I could find. I found out about HarfBuzz, which is a much lower-level text layouting library, and supposedly actually what Pango uses under the hood, but for some reason when using it directly I had no issues, which is weird.

But I'm happy that this worked, and is lighter-weight, even if it means I'll have to deal with line breaks and such myself, which HarfBuzz does not provide.



This particular test application only uses HarfBuzz to layout the glyphs, FreeType to get the corresponding pixels, and then I just copy them over to an SDL surface/texture (which will be an OpenGL texture or w/e in the actual engine of course), ready to be rendered. The (very incomplete) HarfBuzz documentation said something about "built-in OpenType support" so maybe I don't even need the additional dependency of FreeType either. Will look into it, I guess!

[Schrompf]

This looks really useful! I'll try it myself if I can't get my hands on a cheap Slug license.

[oahda]

It might have changed since, but IIRC I asked if Slug supported non-Latin scripts (besides emoji) and they said no and didn't seem to really have any plans on fixing that either. ):

[Schrompf]

Wut? I thought I read a tweet that they're supporting all of it. Gotte recheck, thanks for the heads-up.

[edit] Found it: https://twitter.com/SlugLibrary/status/1001933249122201600

From the example images it looks like at least they support right-to-left languages. Unsure about vertical layout like your chinese example.

[oahda]

Oh? Do tell if you find that to be the case! c:

[Schrompf]

Just found it. Updated my post. Sorry for the ninja'ing.

[oahda]

Oooh, fantastic. I won't personally be using anything that requires a paid license, but that's great news for those who will!

[ferreiradaselva]

You might remember I was having issues with combining diacritics using Pango for text rendering...

Since I'm still set on having good international text support in my game engine, I decided to see what else I could find. I found out about HarfBuzz, which is a much lower-level text layouting library, and supposedly actually what Pango uses under the hood, but for some reason when using it directly I had no issues, which is weird.

But I'm happy that this worked, and is lighter-weight, even if it means I'll have to deal with line breaks and such myself, which HarfBuzz does not provide.



This particular test application only uses HarfBuzz to layout the glyphs, FreeType to get the corresponding pixels, and then I just copy them over to an SDL surface/texture (which will be an OpenGL texture or w/e in the actual engine of course), ready to be rendered. The (very incomplete) HarfBuzz documentation said something about "built-in OpenType support" so maybe I don't even need the additional dependency of FreeType either. Will look into it, I guess!

Good job!

[Ordnas]

Very nice 

[oahda]

And now I got it working with the single-header, basically zero-dependency STB library stb_truetype for rendering the glyphs instead of FreeType, ridding me of that big, nasty dependency, which I really don't want to have to figure out how to compile for all my target systems. <3

Only issue I hit an assert and crash if my font size is set greater than 41 em, so I'm trying to figure that out…

EDIT:
Out of curiosity I just commented out all the asserts that I was hitting and the program ended up rendering the text just fine. There was one issue causing unintended lines to be drawn but I realised I could fix it by changing one of the asserts to an if…

The lib draws the glyphs scanline by scanline, and the whole crash issue was an assert checking if it was out of bounds, and I noticed it was always less than a pixel off, so I figured I could just ignore it instead of asserting, not like a lot will be cut off…

I'm a horrible, nasty hacker, and perhaps I'll have problems down the line, but if I've understood the code correctly I actually don't think so…

BEHOLD, same as before but with stb_truetype instead of FreeType!

[Ordnas]

You just need to remember in the future that you commented the asserts for that issue and you will be fine  

[oahda]

Yeah, and unless I have issues in the future there's really no reason to ever update stb_truetype anyway so I can just keep my old, edited file around (and the edit only takes a minute if I ever need to do it again). C:


Bit of a lengthy post here! Just documenting my process in case I ever need to go back and do something again or in case someone else finds the information useful, since it took me all day to mess with this!

Yesterday I did some more work and got text alignment (left, middle or right) working and multiple lines working.

Today I wanted to get bidirectional text working, so that I can put LTR and RTL characters in the same string (might not be too common to completely mix scripts in a properly localised application, but the numbers used in the Arabic script are actually LTR despite the letters being RTL, so there are things like that still which are important!).

Getting that working basically means having an algorithm (as standardised by Unicode) that goes over the input string and reverses the order of characters where necessary so that the whole string can then be rendered as normal with just one directionality.

HarfBuzz does not provide this functionality, so external libraries are necessary…

• First I tried fribidi which forced me to go through a makefile process, slap tons of files on my project and write loads of code to get my reordered string back, only for me not to get it working anyway—nothing happened to the string.
  
  
• While I was googling the issue I found out about the alternative library minibidi which is just a single file with no dependencies and you only need to call a single function that automagically does everything for you—and I got it working almost immediately!
  
  
  • I can't find the actual source file on the author's website or by searching the web, but the code can be found here and there and I used this version (worth noting that the malloc.h included at the top does not exist on every system, so I changed that to stdlib.h— I also turned the file into a header instead of a source file).

And here we are! Before and after applying the bidirectional algorithm:





If you're not familiar with Arabic, ١٠٠ is the number 100 and as you can see the digits are in the same order as with the Hindu-Arabic numerals English uses despite the RTL nature of Arabic and the fact that you input them in the same order as you input 100 (one-zero-zero, not zero-zero-one).

Worth noting if you're reading this because you want to implement it yourself:

• The only minibidi function you use, as clarified by the documentation comment in the code itself, is doBidi(); the two boolean arguments should be false and true respectively, and you can ignore the last two parameters and just put in null; the string you pass as the first argument will be reordered so just read it back after you call the function.
  
  
• After the bidirectional algorithm is applied, the text now behaves as LTR instead of RTL, so just lay it out with HarfBuzz and render it with stb_truetype as LTR now or it will look wrong!
  
  
• minibidi uses proper Unicode codepoints and wants 32-bit strings, so you'll have to properly convert if you're using regular old 8-bit strings like I am. If you're not familiar with the modern C++ utilities for this, check out std::u32string and std::wstring_convert!
  
  

[Schrompf]

Oh nice. I never heard of stb_truetype before, but now I have, and I can get rid of one whole subproject throwing loads of warnings on 64bit builds. And I didn't even know that back-to-front text is even an issue, let alone that it can be solved so easily.

I wonder why it's so complicated. Detecting all the RTL characters, group accordingly, inverse RTL groups, inverse overall group sequence. I probably missed something and am thinking too shortly, but this task should certainly not require a whole library with Makefiles and stuff.

Gah, how I hate the C++ build system. Come forth, C++20 modules, and rescue me!

[oahda]

I wonder why it's so complicated. Detecting all the RTL characters, group accordingly, inverse RTL groups, inverse overall group sequence. I probably missed something and am thinking too shortly, but this task should certainly not require a whole library with Makefiles and stuff.

You'll have to read the aforementioned standard for details on the algorithm.

Gah, how I hate the C++ build system. Come forth, C++20 modules, and rescue me!

Yeah. Later yesterday I got HarfBuzz building from source as part of my project as well, so now I've finally gotten to the point where there is no need to link anything, so everything needed to get this working is just the source code itself now, which is great (I mean, there are "dependencies" like the STL or C standard library, but at least for my purposes those are always expected to be present). You just drop it in a project and it works without setting anything, except for two necessary defines, up.

I'll probably just package the whole thing into a little library that's separate from the rest of my game engine that can take text input with optional tags and hooks for formatting and spit out bitmaps so that I, and perhaps others, can reuse this in the future. Proper text rendering is so important, but for some reason there doesn't really seem to be anything out there that does it all while also being easy to add to a (very) cross-platform project, since there's always the linking, and you never know if there are prebuilt binaries for the system you're targeting, and if there aren't, you have to mess with that and it's so much work…

[oahda]

Started turning it into a C++14 library in case anybody wants to play with it:

https://bitbucket.org/avaskoog/kirja/src

Only does single colour text without formatting so far, but it supports line breaks. You can load a font from file or memory and then render a string to a bitmap with it, with various settings available. That's it. Should work out of the box without linking or any other setup besides adding the kirja/ folder to your include paths, but I've only tried it on macOS so far. There's a small SDL2 example provided. c:

[Wilson Saunders]

For kicks and giggles I programed an A* path finding in Unity then made a little rat to run the mazes.

[Crimsontide]

Finished a CRC implementation in C++.  Nothing spectacular but with the new C++17 constexpr capabilities (or perhaps C++14... I can't keep em all straight) I could compute the look up table directly at compile time.  All the performance and none of the copy-paste hassle of generating and copying them by hand

[RalenHlaalo]

Here is all 26k lines of Pro Office Calculator on one page. Really puts the scale of it into perspective. By far the biggest project I've ever managed to finish

https://gist.github.com/RobJinman/f5326ee40e99181b71553bf82083fa2e

[Schrompf]

Again a Gamejam entry I managed to put together over the weekend while still tending to my family most of the time. Again in C++ using my framework and source my other projects. Overall I put roughly 10h of work into this game.

And as usual: there's not much of an actual game, but I had fun developing the technology. The world is a point cloud with a few million points. And for a while now I wanted to try out an "aliasing-free" renderer where pixels in a rendertarget are not treated as  single point samples (or multiple samples) but as real areas whose area integral I wanted to solve analytically.

Simply put: I have points. Points have a shape. If the shape is simple enough, I can exactly calculate how much area of a pixel is covered by the point shape, and blend the pixel colour accordingly. The current renderer is geared towards grayscale only, and uses 24bits of precision to handle the microscopic point shape sizes of distant points. And it's only supporting rectangle-shaped points for now, because solving the integral for a circle turned out to be a hefty formula with asin() and sqrt() in it. Some day I'll try that, too.

But the results are quite nice. A very stable and flicker-free image when moving the camera even in ultra-low resolutions. The gamejam's topic was "restrictions", with one restriction being a resolution of 80x60. So this the default setting, but you can turn up the resolution up to 1280x960.

Bonus: I put my fiber-based parallel job system to work and parallelized most of the rendering, and it *seems* to roughly scale with the number of cores. Internal implementation details will prohibit scaling beyong 16 cores, but my Core i7 with its 4+4 cores achieves performance close to 4x the single core speed. And I implemented a slice-based alloc-free parallel depth sorting for the points which sorts some few million points in <1ms. I'm quite proud of that, too.

The current build is here: http://www.splitterwelten.info/privat/act5.zip

Look around with mouse, move with WASD or cursor keys, hold Shift to run, NumPad Plus/Minus to switch resolution. Ignore the white sparkly thingys, those were my 11:45pm try to add some meaningful play mechanic, but for the moment they don't do anything.

Images: