Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the OpenGL layer safe? #117

17cupsofcoffee opened this issue Apr 15, 2019 · 3 comments


None yet
3 participants
Copy link

commented Apr 15, 2019

...probably not!

This is a tracking issue for ensuring that the OpenGL layer in Tetra makes correct use of unsafe, and that there's no way to cause undefined behavior via Tetra's API.

Long term, we might want to move to using a more established library for the graphics backend (#51), but in the short term we should probably at least avoid shooting ourselves in the foot.

Issues found so far:

  • #1 - OpenGL handles can be used-after-free if the context gets dropped

This comment has been minimized.

Copy link

commented Apr 18, 2019

I wonder how much it maters? At some point u decide that all new development is against Vulkan... Though I know it's not well supported on OSX, there are projects looking to fix that.


This comment has been minimized.

Copy link

commented Apr 18, 2019

Instead of targeting Vulkan directly a better approach is to go for something like gfx-hal for a lowl-level/unsafe abstraction over the three modern graphics APIs (dx12, metal, vulkan) or for a higher level safe option like wgpu, venturing into the latter recently.


This comment has been minimized.

Copy link
Owner Author

commented Apr 18, 2019

gfx-hal is definitely on my radar (and I'd definitely choose that route over raw Vulkan) - the main blocker for me switching is that I haven't been able to get it working with SDL (and I don't really want to switch to Winit for various reasons). That said, I know this is definitely possible, because Sev on Discord has managed to get it up and running.

Also the API is complicated and it scares me :p

Either way, discussion of switching backends entirely would be a better fit on #51 - this is more for ensure that our current backend isn't going to shoot people in the foot in the meantime :)

@17cupsofcoffee 17cupsofcoffee pinned this issue May 6, 2019

@17cupsofcoffee 17cupsofcoffee unpinned this issue May 6, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.