Hello everyone,
Update 0.22 is now live 🎉
This update focuses on a number of major technical challenges that have been postponed throughout Early Access due to the time and complexity required to address them. Unfortunately, by the time I got to them, I had also reached a stage where I could no longer sustain working full-time on the project. The combination of these factors pushed back the consistent monthly update schedule that I’ve maintained throughout Early Access significantly.
I’m still figuring out the best approach for future updates. There are two main options: smaller, more frequent monthly updates, or updates with a similar scope to previous releases that ship simply when they are ready. For now, I’ve decided to go with the latter. This means updates may be less structured, but the goal remains the same: continue making progress and, ideally, reach the stable version 1.0 with the roadmap completed before Christmas.
As always, thank you for the continued feedback, reports, and patience, it helps shape each update.
- Fred
Patch Notes
Fonts System
Card Engine now supports dynamic OS font discovery, including custom fonts installed directly on your system. Instead of relying on a predefined whitelist of fonts, Card Engine automatically builds its available font collection at startup based on the fonts directly provided by the operating system. This makes the font pipeline significantly more flexible and adaptable
Keep in mind that the font scan is performed only once during application startup. If new fonts are installed while Card Engine is running, the application must be restarted before they become available
Added fallback support for Thai characters
Reduced memory usage associated with system fonts by optimizing how font data is loaded and stored internally. This is especially noticeable for projects using many different fonts or multiple writing systems, where previously unused font data could contribute a lot of unnecessary overhead
Improved internal font processing efficiency
Improved loading speed of system fonts
The whitelist-based Texts package pipeline has been deprecated in favor of a new dynamic font category, which is built automatically during application startup based on what fonts are found on the OS. The original Texts pipeline still exists internally to preserve compatibility with existing projects (e.g. Arial is still Arial. This is entirely just how the font data is sourced.)
Improved font compatibility as part of broader localization work, including better handling of languages that rely on different character sets and writing systems. These changes provide a more consistent foundation for future localization support
Expanded support for non-Latin character sets, including Chinese, Japanese, Russian, and other extended writing systems
Improved consistency when the system switching between primary and fallback font rendering ensuring outlines, shadows, and other styling remain persistent
Replaced the collection of individual compatibility fixes and workarounds for non-Latin characters introduced throughout Early Access with a proper foundational implementation
The legacy toggleable Texts package has been removed from the Package Manager with the introduction of a new “System Fonts” category. The only real change you will notice here is the amount of fonts in the asset browser as well as the category being “System Fonts” rather than “Texts”. Users on non-Latin based systems might notice a more drastic change to what fonts they have available
Fixed an issue where text shadow data could become corrupted when characters were rendered through the font fallback system. This caused shadows to appear at a reduced size before snapping back to the correct size when adjusting the horizontal or vertical shadow offset
Improved handling of non-Latin characters rendered through fallback fonts, addressing a deep architectural issue where both outline and shadow data could occasionally be lost for certain glyphs. This resulted in missing or inconsistent visual styling. Although the issue could not be reproduced consistently and has not reoccurred at all following these changes, it will continue to be monitored as a known issue until sufficient time has passed without further bug reports
Asset browser
Moved a significant portion of the asset preparation work previously performed when opening individual asset categories for the first time into the project loading sequence. This shifts the work to a predictable point when opening the project, resulting in faster and more responsive category navigation afterwards
Removed the Custom asset license banner from the Asset Browser and Image Picker. Importing custom assets is now assumed to imply user responsibility for ensuring appropriate usage rights. The remaining personal and standard license banners has been moved to the bottom of the interface, providing a slightly larger viewing area
Preview fonts are no longer displayed in bold
Removed category prefixes from font display names (e.g. Arial instead of Texts_Arial) as the prefix provided no real benefit. This will make the list as a whole significantly cleaner
Template System
Previously, image highlights were only applied together with the image asset as a grouped toggle. Highlights are now handled as its own, unique toggleable option within the Apply Template changes window
Card Editor
Removed category prefixes from font names in the font selection dropdown
Fixed an issue where long text entries could cause the editor's text input field to scroll incorrectly, making portions of the text within the field disappear until the object was deselected and selected again. The scrolling input field behavior has been removed, and the whole field now expands dynamically as text is entered instead. If the text is so long that the field exceeds the screen, it will naturally work with the editor column block scroll view
Newly created text elements are no longer bold by default
The selected font label beneath the text editing field no longer includes the category prefix
CSV System
Fixed an issue where the CSV importer and exporter could fail to correctly import or export back-side card data
Database
Fixed an issue where project-specific custom assets were not unloaded when returning to the main menu
Fixed an issue where custom assets could fail to load from disk and display red warning triangles when their category names contained the _ character. This character was originally intended to be restricted because it is used internally as a data separator, but a previous validation change unintentionally allowed it. Instead of invalidating existing projects by enforcing the old restriction again, the asset retrieval system has been updated to correctly handle these names going forward
Fixed a rare crash that could occur when importing large batches of assets containing one or more unsupported file formats
Fixed a long standing issue where some users experienced extreme memory usage
Custom asset loading and memory optimization
Resolved a long-standing issue where excessive memory usage could make Card Engine outright unusable. A user provided valuable insight that eventually allowed me to finally reproduce the problem on my end. You know who you are, thank you!
The issue was caused by importing extremely high-resolution images into custom asset folders. While these images may only occupy a few megabytes on disk thanks to compression, Unity (which Card Engine is built on) must decode them into full pixel buffers in memory. As a result, using custom assets (images) at resolutions such as 7000×10000 pixels could consume extreme amount of RAM.
The challenge was that users may intentionally keep source artwork at these resolutions for external editing workflows. Many pixel editors recommend working at least 2× the target resolution to minimize quality loss during resampling. However, since Card Engine only renders these images and never modifies the original source files, those extreme resolutions provide no practical benefit inside the application.
To solve this, Card Engine now dynamically scales image data when loading from disk whenever an image exceeds the maximum import resolution, configurable from the settings panel. The original source files remain completely untouched on disk, allowing users to continue editing them externally while dramatically reducing memory consumption inside Card Engine.
This optimization introduces additional processing whenever images are loaded from disk. While the impact of loading a single image is minimal, it became much more noticeable when an entire asset category was initialized using the previous lazy-loading approach. To address this, Card Engine now performs much of that work during the project loading sequence instead. Since most users eventually browse their custom asset categories anyway, this provides a smoother overall experience by front-loading the processing and eliminating interruptions later while browsing assets.
Optimized image resolutions are still recommended for the fastest loading times and best database performance, but projects containing extremely high-resolution assets should no longer experience excessive memory usage.
NOTE: If you notice very obvious degradation in asset quality after this update, ensure you check the settings and adjust the max import pixel size, then reload the project. Again, the original source files remain completely untouched on disk. If you absolutely need a resolution larger than the highest possible to set in the UI, you can edit the raw number in Settings.xml found in your project folder, where you can set "MaxImportedImageSize" to any whole number. (Like 10000, if you absolutely need it, despite the memory cost)
Loading bar (Project loading)
Now only shows the raw task number (e.g. 14/86) and now that a large chunk of the initial category opening work has been moved to the project loading sequence, it will also show the name of the category currently being processed, making it easier to identify which category may be contributing most to the overall loading time
Other Changes
Card Engine no longer creates project snapshots when opening projects created in older versions. This safeguard was originally introduced as disaster recovery for a rare issue that was resolved almost a year ago. With that bug long since fixed, snapshot creation has become unnecessary and only increased project loading time.