Absolutely, it's what it's there for! As some people mentioned in the comments switching to SSBOs for the text would be a big performance improvement for an engine.

That's great! You must have put a lot of work into that engine!

Haha just when you thought you'd never have to experience this again!

Update: Its likely an issue with the Antonio-Bold font. I dont see the issue when using the regular or the light version of the font. Guess fonts have to be compatible with this library.

You are 100% right about the texture arrays! Haha I burned like 6 hours trying to figure out some issues with them. That's awesome about the texture rendering! I really need to learn more about SSBO's sounds like you added a nice improvement. Thanks for the feedback and positivity, I really appreciate it!

Yeah, you're correct that if the text is guaranteed to be static then you could send data in the VBO to be faster. It's just when you start having to modify the text that that becomes efficient. We saw that with the initial implementation. Modifying the often VBO can be expensive. Additionally, if you knew strings wouldn't change frequently then you could implement a two step system. Where the first step is the text rendering we're dicussing but at the end you save the resulting image to a texture. And the second step just draws that prerendered texture. That way if the text doesn't change you can skip the first step each frame. I've been meaning to implement them for a while! My game needs smoother text so I looked into them. I'm hoping to implement them in the near future then do a programming video on it.

@@WhateversRightStudios for even more smoother text check out the msdfgen (it generates multichanneled SDFs, or MSDF for short) If you have read something about SDF, it would be very simple to explain how MSDF works: So, basically, MSDF is just multiple SDFs, and by picking the median one (the middle value of 3 of them) you can achieve very sharp edges About text itself: I prefer the atlas approach, where you generate the atlas and use it in multiple text objects in the scene, so you'll have a single shared texture to generate next texts significantly faster than regenerating textures, so you can collect the whole translation characters into the one collection, generate the atlas and then you'll have to generate only VBOs in a further texts P.S. SDF and MSDF are not only for text rendering, you can utilize them as rasterizer for vector graphics and achieve vector-look-a-like from raster info (tbh, you should treat them as fields as the name says, rather than rasters)

Odd errors as none of the shaders on GitHub have that many lines. But based on that error your array size is too large for your GPU. Also double check your GPU supports OpenGL 3.1 and up

For who happens to have this error, just lower the transforms array size to 200 and all good

I wouldn't say so, it's true that ogl and d3d11 and below are pretty strict to perform a lot of micro-optimization (multi-threaded filling command lists, for example). But in linux ogl is definitely better than d3d simply because it wont carry with him bloat called wine (wine is for not ported stuff, native is almost always better) P.S. I'm choosing opengl only because emscripten has gles3 emulation on webgl2 so I can write almost the same code for multiple platforms. In win-only projects d3d11 is my favorite, btw, but only because I'm just more familiar with it

@@NyanCoder wine? maybe that was true a long time ago. now we have steam proton stuff which I think runs very well

​ @stephenkamenar sorry, I don't use steam on my linux, for games I have Windows install, so maybe I'm a little bit out of context. Btw, doesn't it use wine for os imitation and providing libraries that used by exe's? Basically my point is the compatibility layers have a bunch doubling stuff for basic things (memory allocation, work with files, console output, access to hardware, creating threads/processes, memory protection like mutex, application window api, e.g. winapi), for example a lot of dll's should be provided (such as kernel32.dll, user32.dll, d3d11.dll and more), and memory and process management should be doubled for Windows executables in other way (the exe is structured different, also the things in windows and linux done in different way, for example to output to console in linux you need to int something, and in windows the kernel32.dll provides functions to work with files and the file-handlers that are bound to console window), also they have their own set of libraries (ogl+vk vs ogl+d3d+vk, cpp runtime, x11+wayland vs winapi, etc.) And that makes you basically have multiple things that do the same thing (ofc some things are just wrappings, but a lot of thing are dupes). That what I call bloatware. It's better to have multiple native builds for each system (win32, win64, win-arm, linux32, linux64, linux-arm), and compatibility layers are for apps that are not ported, not for developing in the first place. The people that are interested only in your application and not in any other unsupported stuff shouldn't be forced to carry too much bloatware P.S. I'm rereading my letter and noticed that I wrote it in a way that hard to keep in track, sorry if it's hard to read for you too

@@stephenkamenar What do you think Proton is in it's core? It's customized Wine by Valve. Just like Steam OS on Steam Deck is customized Arch Linux. Finally OpenGL isn't piece of trash.

@@wiktorwektor123sure but it's easy to use and stuff now. old wine was too annoying to use