This card is a place where we can discuss the high level goals for FRB. Items listed here are not commitments, but rather general ideas which may or may not be realized.
FRB Dark Mode
Highly requested feature and it's something I also personally want. It's in progress now.
FlatRedBall Engine on FNA (DONE)
FNA seems to be far more active than MonoGame, especially for those targeting AOT and consoles. This includes:
Creating a new version of FRB engine and all assocaited libraries which link to monogame (Forms, StateInterpolation, Gum)
Supporting and recognizing this as a new project type in Glue
Adding support for this in the new project creator
Adding new nuget packages
Testing, testing testing
FRB MDX (which used to be supported by Glue, but is no longer supported) did not have the concept of a Content Pipeline. Since then , both XNA and MonoGame did, so Glue was built around that. There is some work to be done here to bring back the concept of from-file-only projects rather than using the content pipeline.
Separate Tiled into FlatRedBall.Tiled .dll
Currently Tiled is generated into projects. This causes a few problems:
It requires a lot of #if VERSION code to support certain features
It adds codegen that the user never really wants to edit anyway. This was originally done to indicate that Tiled was not a core tech but now it is core to almost all FRB games
It prevents users from using Tiled in code-only projects
It makes editing Tiled code in projects when bug fixing more difficult, as the changes have to be made or copied over into Glue's Generated code. Furthermore, Glue's generated code is generated rather than compiled into a library, so code isn't error checked there.
It makes nuget packages and additional expansion on this code near impossible.
This will require a new GLUX version as to prevent further generation of Tiled code.
Gum on Avalonia/Skia
This is a huge project but realizing this provides a number of benefits:
Gum core libraries could be upgraded to .NET 6 allowing the same set of libraries to be used in all projects. Currently code is shared, but the libraries vary quite a bit between FlatRedBall game implementation, Gum tool, and Skia Gum.
Gum could run on Mac/Linux
Skia could become a core rendering engine greatly improving pixel-perfect issues
Skia could be used for text rendering, immediately expanding all character sets, providing support for better styling, and embedded (markup) styling in a text block. This also provides more precise control over text sizes including line height, and measuring with or without padding around text blocks.
Remove one of the reasons why users must install XNA ruintimes.
AnimationEditor Embedded in FRB
This work has already started and is happening incrementally. Benefits:
Move to a more flexible PropertyGrid (DataUiGrid)
Remove one of the reasons why users must install XNA runtimes.
Remove the requirement to install Visual Studio 2019 (AnimationEditor does not compile in VS 2022 due to XNA issues)
Upgrade to modern patterns for easier maintenance
FlatRedBall on WebGL
Currently FlatRedBall does not target WebGL as a platform. I'm not sure if MonoGame is mature enough to handle this - I think there is some early work here, but I'm not sure how much has been pushed.
By contrast, KniEngine seems to be very active and is pushing WebGL, so perhaps this means a version of FRB running against Kni targeting WebGL.
Currently the FlatRedBall PluginBase is defined in GlueFormsCore which is built against WPF. The PluginBase provides a number of methods which use WPF objects. This means that a console app, or a .NET 6 library without WPF, would not be possible. We would like to have a core library for FRB which is not tied to any display technology, but which can still lead a .gluj and associated files and do full codegen and project management.
This could be something that another tool could use as a .dll or as a command line app allowing the front-end of Glue to change.
Separation of FlatRedBall.Forms from FlatRedball
Currently FlatRedBall.Forms requires using FlatRedBall since it is based on the underlying InputManager, Cursor, and Gum event system. Most of FlatRedBall.Forms is built on Gum which means it could be used in contexts outside of MonoGame.
Gum on Avalonia/Skia (actually will be Avalonia/Monogame)
FlatRedBall.Forms from FlatRedBall - this currently exists in MonoGame but doesn't have all of the functionality. Progress is being made here slowly to unify FRB Forms with MonoGame Gum Forms.
These have not been started:
FlatRedBall Plugin Separationn from WPF - this may never happen, or at least is not currently planned.
Separate Tiled into FlatRedBall.Tiled .dll - no plans to start on this yet, may not happen for a long time as it is very low priority for FRB projects where everything already "just works"
This card is a place where we can discuss the high level goals for FRB. Items listed here are not commitments, but rather general ideas which may or may not be realized.
FRB Dark Mode
Highly requested feature and it's something I also personally want. It's in progress now.
FlatRedBall Engine on FNA (DONE)
FNA seems to be far more active than MonoGame, especially for those targeting AOT and consoles. This includes:
FRB MDX (which used to be supported by Glue, but is no longer supported) did not have the concept of a Content Pipeline. Since then , both XNA and MonoGame did, so Glue was built around that. There is some work to be done here to bring back the concept of from-file-only projects rather than using the content pipeline.
Separate Tiled into FlatRedBall.Tiled .dll
Currently Tiled is generated into projects. This causes a few problems:
#if VERSION
code to support certain featuresThis will require a new GLUX version as to prevent further generation of Tiled code.
Gum on Avalonia/Skia
This is a huge project but realizing this provides a number of benefits:
AnimationEditor Embedded in FRB
This work has already started and is happening incrementally. Benefits:
FlatRedBall on WebGL
Currently FlatRedBall does not target WebGL as a platform. I'm not sure if MonoGame is mature enough to handle this - I think there is some early work here, but I'm not sure how much has been pushed.
By contrast, KniEngine seems to be very active and is pushing WebGL, so perhaps this means a version of FRB running against Kni targeting WebGL.
https://github.com/kniEngine/kni
FlatRedBall Plugin Separation from WPF
Currently the FlatRedBall PluginBase is defined in GlueFormsCore which is built against WPF. The PluginBase provides a number of methods which use WPF objects. This means that a console app, or a .NET 6 library without WPF, would not be possible. We would like to have a core library for FRB which is not tied to any display technology, but which can still lead a .gluj and associated files and do full codegen and project management.
This could be something that another tool could use as a .dll or as a command line app allowing the front-end of Glue to change.
Separation of FlatRedBall.Forms from FlatRedball
Currently FlatRedBall.Forms requires using FlatRedBall since it is based on the underlying InputManager, Cursor, and Gum event system. Most of FlatRedBall.Forms is built on Gum which means it could be used in contexts outside of MonoGame.