spectralcascade / ossium Goto Github PK

Noticed on Linux laptop (dual core CPU with HD integrated graphics). Possibly float rounding issue? Specifically, when a glyph is too big to fit in an atlas cell so it is downscaled and then upscaled back at rendering time. At mip level 0 it seems correct but at other levels squished glyphs seem wrongly scaled.

Works fine on my 64-bit Windows system (AMD Ryzen 7 CPU) with mingw and codeblocks (using C++ 17 standard with GCC), however causes a segfault on my dual-core 1-ghz laptop (Linux, I think an AMD cpu). Seems plausible that the memory layouts are different :/ though I'd be surprised as I'm using GCC for both builds.

Suspect the text component leaks memory whenever recreating the texture.

Rather than updating the scene or tree directly, when an entity is destroyed, it should null it's node's data but not remove it from the tree. The scene can deal with the tree and child entities

For some reason I have to update the text layout every frame before rendering, which is horribly expensive

In some configurations, certain editor window borders cannot be dragged to resize the windows. Likely this is a simple logical issue in my resize computations.

global::delta.time() is currently returning the correct value before and after the UpdateComponents() call in main.cpp, but within the method global::delta.time() returns 0! Highly suspect there's some corruption going on.

Not sure what's going on exactly, have left a TODO in main.cpp

Could be because of aspect ratio code? Doesn't seem to be a crash

Another memory leak; I believe it is due to the text class not freeing something properly. This is a pretty critical bug as it means drawing lots of text with DebugDraw every frame adds a lot of junk to the RAM quickly

The final entity in the hierarchy seems to be incorrectly parented when a scene is loaded.

Removing a component from the scene doesn't remove it as an entry during serialization. Maybe we don't cleanup the entity properly?

Whenever a new DebugText is constructed, the text has to be rendered to a texture. As a result things can get slow if you're drawing some text in a different position each frame, even if you haven't changed the actual text. We should find a way to cache things like this where possible.

There's currently a crash when attempting to use memcpy() in Texture.cpp (used for pixel manipulation) - for the timebeing I have simply disabled pixel manipulation in that method.

Need to account for this. It's rather noticeable when resizing a window and all the text disappears because the font texture atlas got destroyed!
https://forums.libsdl.org/viewtopic.php?p=42107

Specifically, I removed the one and only context setup on the InputGUI, then tried adding another interactable, and it really didn't like it