Thomas Altenburger
Thomas Altenburger
From a personal perspective and coding style, I don't think that we need a pool and that a static byte array that we grow if needed is likely enough.
> In terms of graphics planning, I believe one of the aims stated was to implement multithreaded graphics API support (such as drawing on one thread while using creating/set/get on...
```win-arm64``` is an RID that we currently haven't planned to support, for both the developer experience and runtime. Unless someone is willing to contribute automated building of all dependencies to...
It's not just about these dlls and there is more to it than what your project needs to have a proper experience on win-arm64. Since win-arm64 isn't natively supported by...
That would be welcome.
I understand that some of you are excited about hardware and stuff, but here's the truth based on Steam's hardware survey (which is very relevant in regard to hardware market...
> I've done a few win-arm64 PR's for SDL and OpenAL Speaking of which, for the time being these changes are on their own (nameless) branch and not merged into...
Correction: they got merged into ```main``` (although the git history is misleading on this one because a tag has been put on a dead branch). Although, it's incomplete, ```win-arm64``` is...
We have a couple of steps to validate to start supporting ```win-arm64``` officially: - We need some testing on #8737 (especially if your projects are building shaders) - We need...
Is this in a totally empty project?