search

ppy / osu-framework

A game framework written with osu! in mind.
MIT License
1.64k stars 409 forks source link

Decouple framework from osuTK #2448

Open swoolcock opened 5 years ago

swoolcock commented 5 years ago

Proposal to decouple the framework from osuTK, eventually removing it entirely.

At this point it is possible to create a branch entirely removing the osuTK libraries, so that we can focus on testing and implementation parity.

Regarding Color4, @smoogipoo has suggested we migrate the existing type from osuTK. If this is the path we take, it may be an opportunity to migrate the functionality into a new RGBColour or LinearColour type to go alongside the existing SRGBColour. This would also avoid the issue of needing using Color4 = osu.Framework.Graphics.Colour.Color4 in the interim (since there will be a conflict in any files currently importing the osuTK.Graphics namespace).

Regarding OpenGL, the SDL PassthroughGraphicsBackend currently injects GL functions into the osuTK GL class, so we should be able to do something similar in the reverse direction.

Regarding System.Numerics, there may be some type massaging required as it does not include a Matrix2x2 or Matrix3x3 type, only Matrix3x2 and Matrix4x4. We may need to use SN Matrix4x4 to represent osuTK Matrix3, and either SN Matrix4x4 or SN Matrix3x2 to represent osuTK Matrix2.

peppy commented 5 years ago

We haven't yet decided a path forward as for what we are going to do about the backend, but SDL (+veldrid), OpenTK 4.0 etc. are possibilities.

While this isn't an imminent focus for us (would rather get android pushed out and continue game implementation) you are more than welcome to continuing abstracting the remaining opentk links we have, as I see this as a good move regardless of the path forward.

swoolcock commented 5 years ago

As part of reorganising the exposed events and bindables, I’m thinking that key and mouse events should not be part of the IWindow interface, as we expose those through input handlers. The concrete window implementation would delegate OS input events through to the handlers automatically.

Additionally, I'm going to try to do this in bite-sized chunks or it will become a huge PR that's impossible to review. Note that there may be breaking changes along the way, but I'll make sure to keep osu! up to date with them.

swoolcock commented 5 years ago

Pushed WIP branch for discussion: https://github.com/swoolcock/osu-framework/tree/gamehost-refactor

swoolcock commented 5 years ago

After some more work on this I've successfully split the window/audio/input/video initialisations and encapsulated them mostly within the backend implementations.

As for graphics, most of the current OpenGL references are within the osu.Framework.Graphics.OpenGL namespace, and already wrapped by the framework. I'm hesitant to redirect it through an abstraction layer, as we would essentially be cloning what Veldrid does already.

Replacing the graphics API is already going to require rewriting shaders to a degree, so I feel it would be better to just make a decision on which path we are taking and replace osuTK in one go.

swoolcock commented 5 years ago

Note that Veldrid uses System.Numerics for vector primitives, and has its own RgbaFloat and RgbaByte colour structs.

huoyaoyuan commented 4 years ago

Note: several primitive types in System.Drawing (including Color, Rectangle) are a part of .NET Standard since 2.0. (https://docs.microsoft.com/en-us/dotnet/api/system.drawing?view=netstandard-2.0) Unlike other apis under System.Drawing that actually "draw" something, they are totally platform-agnostic.

smoogipoo commented 4 years ago

I'm not sure if Color is serialisation-friendly for us. RectangleF seems to be, but I'm not entirely sure we should be relying on using netstandard types for the purposes of drawing in general, and we may still need our own types that have the structure which the graphics API expects.

swoolcock commented 4 years ago

I've been trying to expose all two-dimensional measurements with System.Numerics.Vector2 in my SDL2 PR, even for size measurements. As for colours, we potentially have the option of going with Veldrid's RgbaFloat which is backed by a System.Numerics.Vector4.

wooster0 commented 4 years ago

Have you also considered using GLFW rather than SDL? GLFW is a more modern alternative and it's more lightweight if you only need to handle input and window stuff.

jai-x commented 4 years ago

I believe GLFW does not have mainline support for mobile platforms which makes it unsuitable. Furthermore, the graphics that wraps library in use that wraps SDL2, Veldrid, allows for use of multiple Graphics backends such as DirectX and Vulkan as well as OpenGL support which is a feature that may play into optimisations into the future.

swoolcock commented 4 years ago

I've tried GLFW before, and while it's certainly a possibility, Veldrid has SDL2 bindings built-in and is the preferred window shell.

swoolcock commented 4 years ago

I have updated the issue description to better represent the current state of migration.