piegfx / pie Goto Github PK

This is a maybe, I will have to think about this.

IGLContext is from Silk.NET.Core which is a third-party library. As GraphicsDevice.CreateOpenGL is a public-facing API, it wouldn't be good to leave that exposed. I would propose instead that we pass delegates and let us manually create and manage GL contexts as needed.

Various constants used during build.

Planned constants:

• NO_OPENGL - Disable the OpenGL backend.
• NO_D3D11 - Disable the D3D11 backend.
• NO_SHADERC - Disable shaderc.

Old mixr was bad. New mixr is good! Replace Pie.Audio's mixr with the new mixr.

Add graphics resource for things such as buffers and textures

Add UpdateSubresource-like function for graphics resources (instead of having separate functions per object, although not 100% sure on this due to speed and usability)

Add buffer and texture (? If opengl supports this?) mapping, alongside the existing update methods which will not change functionality (i.e. on direct3d buffers will be mapped if they are dynamic)

Merge Pie and Pie.ShaderCompiler into one project, or more likely reverse the dependency (aka Pie references Pie.ShaderCompiler)

The latter two will be part of the OpenGL 4.3 implementation (might up that to 4.5 to get DSA support)

• GL textures seem to use unsigned byte - this means they won't support floating point textures, etc.
• Multisampling textures
• Map textures
• Fix texture update function

Hello, by setting the game into fullscreen, the fps get limit to 60 FPS.

Info:
With SDL D3D11 and OpenGL get limited!

This can hopefully allow removal of the GL and DX debugging and just rely on Pie debugging, it will throw exceptions on all invalid calls and will also log useful information if debugging is enabled.

Many features remain untested/have little testing, including but not limited to:

• OpenGL viewport and scissor rectangles
• All texture types except for single array dimension Texture2Ds and Cubemaps.
• Texture updating
• SSBOs
• Geometry and Compute shaders

Currently only GLSL is supported by Pie.ShaderCompiler, and Device.CreateShader (without cross platform) doesn't provide any features to support HLSL either (although please see #22 before continuing)

This issue tracks all features that need to be added before a 1.0 release. If you see any features missing that you would like added, create an issue or add a comment.

Essential

These are essential things that need to be added before 1.0 can be released.

• #16
• #5
• #10
• #3
• #4
• #2
• #11
• #13
• #17
• #19
• #6
• #21
• #22
• #26
• #23
• #37
• #43
• #48

Desired

These are things I would like to implement, but don't need to be implemented for 1.0, instead can be implemented for a later 1.x version.

• #15
• #18
• #33
• #30
• #20
• #7
• #12
• #8
• #9
• #28
• Multisampling textures

As the title says. You create a framebuffer, gpu decides to go to bed and just stops rendering stuff.

I suspect I am just forgetting to unbind the framebuffer when complete, so OpenGL still tries to draw to it.

You can resolve the issue by running GraphicsDevice.SetFramebuffer(null) sometime after framebuffer creation.

This issue does not occur under Direct3D.

I know this sounds stupid but Pie doesn't actually support fullscreen mode. The windowing backend doesn't support it, and it's not been officially tested.

Add controller input support to windowing

Currently, all graphics APIs are housed inside the main project. Although it might be worrying in package size as it will bundle all third-party libraries when being published. It would be preferrable to split each implementation to their own project.

The repo doesn't have any test/delivery pipeline in place, therefore, to help the maintainers, I'll be making a pipeline for the project that requires nothing but pushing a tag and creating a new release in GitHub, as well setting up test coverage with reporting.

Pie.Utils provides a few built-in VertexPositionXYZW structs, and that's about it. It serves no other purpose, all the functions that used to be in it (which weren't many) have been consolidated into PieUtils.

As such, this package serves little purpose, apart from to provide these structs, which imo is not worthy of a separate package.

I'd be interested in some feedback on this - Should I:
a. Remove it?
b. Remove it and move the VertexXyz structs into Pie? (i'm not a fan of this option)
c. Leave it be?
d. Improve it by adding ????? stuff to it?

I am leaning towards option a, but any feedback would be appreciated.