ImageSharpTexLib only handles 8-bit BGRA/RGBA but claimed every non-Nearest
rescale, so Lanczos3 on R16G16B16A16_Float or R16_Float threw. Since the
FreeImage removal no other library implements Lanczos3, so TextureTool now
falls back to Bicubic (DirectXTex) for formats ImageSharp cannot process.
We never request TEX_COMPRESS_PARALLEL, the only path DirectXTex uses OpenMP
for, so it only added a load-time dependency on libgomp.so.1 on Linux and
vcomp140.dll on Windows.
The template engine used the raw name for file names but its safe form
for file contents, so The Quiet Archive.Game.csproj was referenced as
The_Quiet_Archive.Game.csproj. Both now use a compact form of the name
with whitespace removed (TheQuietArchive).
Game Studio saves its own solution, named from the New Project dialog,
so it now asks the template not to emit one (skipSolution) instead of
leaving a second solution behind when the names differ.
New Stride.Templates.AssetPacks package (nuget.org only, fetched on demand)
ships Building blocks / Animated models / Materials / Particles. GameStudio
offers them as checkboxes when creating a game; dotnet new and the stride
CLI instantiate them into an existing game.
Emit dotnetcli.host.json marking updateOnly isVisible:false, add the
dotnetcli fallback host-config name so GameStudio honors it too, and skip
isVisible:false params in the new-project wizard.
The updateOnly and LDR excludes still pointed at MyTemplate/ after the library dir was renamed to MyTemplate.Game/, so updateOnly no longer excluded the game library and it got regenerated. Point the excludes at MyTemplate.Game/, and repoint generated exec references at the session's actual library so bare-named (pre-4.4) libraries link correctly.
The out-of-process extension can't register a TextMate grammar (its generated
manifest can't carry the classic VsPackage/MefComponent assets VS needs). So a
small classic (net472) content-only companion VSIX does just that: it ships the
generated grammar + a companion .tmTheme + a language-configuration, registered via
a pkgdef, giving instant .sdsl/.sdfx coloring in VS.
The grammar and its generator move here from Stride.VisualStudio.Package/syntaxes.
Delivery packs both vsixes into the one NuGet package; PackageInstall installs both
in a single call and uninstalls both.
Generate sdsl.tmLanguage.json from Stride's shader vocabulary (Reserved.cs) via a
.NET 10 file-based generator, so the coloring never drifts from the language.
Not wired into anything yet: the out-of-process extension can't register a TextMate
grammar (needs a classic pkgdef asset). Kept for a future VS Code extension / LSP
baseline; see syntaxes/README.md.
Version the VS package and its delivery nuspec independently of the engine
(VersionPrefix 4.4.0, hand-bumped), with an optional prerelease VersionSuffix
wired through release-vspackage.yml and the nuget pack step; the .vsix manifest
version follows AssemblyVersion (numeric only, suffix stripped).
Fix PackageInstall to uninstall the current extension id (was the stale
Stride.VisualStudio.Package.2022), plus the legacy id for clean upgrades.
Remove the old net472 VSPackage implementation (StridePackage, StrideCommandsProxy,
NShader language service, classifiers, code generators, .vsct/.vsixmanifest) and its
obsolete integration tests, and promote the net8 VisualStudio.Extensibility extension
(built in parallel as Package.New) into its place as Stride.VisualStudio.Package.
Delivery is unchanged: PackageInstall still installs the vsix, and the nuspec/VSIXPlugin
still pack it as tools\Stride.vsix. The nuspec now sources the SDK-built vsix via a
$VsixPath$ token that VSIXPlugin fills from the project's $(OutputPath), so it tracks
$(Configuration)/$(TargetFramework) instead of hardcoding the bin subfolder.
Right-click a solution, project, or .sdsl/.sdfx file in Solution Explorer to
regenerate the shader C# for Stride 4.0-4.3 projects, delegating to the bundled
stride CLI (generate-legacy-shader-code). 4.4+ generates it at build.
Output streams live into a dialog while the CLI runs. Placed on the per-node
"…EXPLORE" context-menu groups (solution/project/item).
The editor's main load path already derived project type from OutputType;
StrideProjectType=Executable was only read in two spots (the VS package and a
dead project-reference path) and set redundantly in every executable head.
- VSProjectHelper.GetProjectTypeFromProject now classifies from OutputType
(winexe/exe/appcontainerexe/AndroidApplication -> Executable, else Library),
and PackageSession.Dependencies uses it (single source of truth).
- StridePackage.IsProjectExecutable checks OutputType.
- Remove <StrideProjectType>Executable</StrideProjectType> from samples/templates.
Unset OutputType falls to Library, matching the .NET SDK default. The Cpp/CSharp
auto-detection in Stride.Platform.props is unaffected.
dotnet new / GameStudio new-game now synthesize MyTemplate.slnx (each
platform exec marked DefaultStartup since .slnx ignores file order for
the startup project). Editor SolutionExtension and 'stride new' discovery
follow. Existing .sln projects keep their format (solution serialization
picks by extension on save).
- migrate 15 tracked solutions; update .slnf paths, workflows, build
files, repo-root markers, ios/android runners, .vscode, docs
- Stride.slnx: drop vestigial x86/x64/Mixed Platforms (solution is
all-managed) and build with Platform=Any CPU; GameStudio listed first
so it stays the default startup project
- Stride.VisualStudio.slnx: Package project first (default startup)
- samples: drop dead AppStore/Testing/Windows configs (no per-platform
exec projects remain, only .Game + .Windows)
These are run, never referenced as libraries, so a lib/ folder made them phantom libraries
(and put the apphost beside the managed dll). All their package payload flows through
BuildOutputInPackage, so BuildOutputTargetFolder=tools relocates everything (exe, dll, Roslyn,
BuildHost, resolver bootstrap) to tools/<tfm>/ with no lib/. NU5128 (no lib/ but has dependencies)
is expected and suppressed - the dependency closure is still declared so it restores.
Point install-gamestudio.targets at tools/. The launcher already probes tools/ before lib/
(UpdateFrameworks + LocateMainExecutable), so no launcher change is needed.
AssetCompiler and ConnectionRouter are referenced in-process (Stride.Editor, GameStudio,
Presentation) AND run as a tool/service. Packing the whole runnable app (apphost + resolver
bootstrap dlls) into lib/ made consumers inherit those dlls and exposed the apphost as a duplicate
of the managed assembly (found as both .exe and .dll), which blocks deps.json generation.
Add a gated StridePackRunnableInTools option to the shared NuGet-resolver targets: it packs the
runnable app under tools/<tfm>/ instead of the build-output folder (lib/), leaving lib/<tfm>/ with
just the reference assembly. Default behaviour (root apps) is unchanged. Opt both in. AssetCompiler's
StrideCompileAssetCommand locator is repointed lib/->tools/; ConnectionRouter needs no locator change
(RouterHelper and the router's service resolution find the exe by package file search).
Runtime assemblies now set <TargetFrameworks> from precomputed props-time sets
(StrideRuntimeTargetFrameworks[/Windows/MacOS]) instead of the StrideRuntime
boolean expanded in Stride.Frameworks.targets. Behaviour is identical (verified
across platform configs); the literal element makes Roslyn MSBuildWorkspace
tooling (LSPs, analyzers) treat them as SDK-style.
TemplatePreprocessor copies MyTemplate.{Platform}/ from a reference template
(NewGame) at pack time for any platform the sample didn't author by hand.
NewGame's library dir renamed MyTemplate/ → MyTemplate.Game/ to unify the
naming with samples so injected csprojs reference the right sibling verbatim.
The C# importer hand-computed msdfgen's scale/translate across three coordinate
systems and got the glyph bounds wrong, producing flat single-distance bitmaps
(garbage SDF). Move the framing into the wrapper: msdfgenGenerateGlyph frames the
glyph from shape.getBounds() and returns the bitmap, pixel offsets and advance, so
the importer does no coordinate math. Rebuild stride_msdfgen for the new entry
point (msdfgen v1.12, FreeType VER-2-13-3).
Tests: TestSignedDistanceFieldFont asserts glyph metrics; TestStaticSpriteFont
gains an SDF rendering frame exercising the importer + SDF shader end to end.
stride-platforms was a near-clone of stride-game and drifting from it (e.g. the
icon refresh only landed on NewGame's copy). Collapsed via an updateOnly
preprocessor symbol that excludes MyTemplate/ + *.sln; UpdatePlatformsGenerator
drives stride-game with updateOnly=true. samples/Platforms/Platforms/ deleted.
The T4-based .ttproj engine is no longer reachable from any live generator;
deleting the project along with its ProjectReferences in Stride.Assets and
Stride.Assets.Presentation and the solution entries.
WPF dialog injection becomes an IDotNetNewParameterPrompt constructor
parameter (WpfDotNetNewParameterPrompt adapter stays in Presentation).
SdtplMetadata also moves here and is linked from the CLI tool.
Virgile Bello