-
Notifications
You must be signed in to change notification settings - Fork 17
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
Investigate rendering alternatives #11
Comments
I have to mention here that changing crates could introduce some problems for old intel graphics cards. Not sure what exactly causes it but it's a known issue in Godot engine where people using GLES3 and 3d without lights with intel hd 620 causes screen to flash rapidly. And it's a very common old card. And more relevant is that Macroquad using it's own graphics library has the same damn issue. It isn't even related to 3d or lighting in this case, I know this because I happen to have a laptop with intel hd 620. Literally just having a non black background or a few other colors already causes the flashing which makes it completely unusable. However building to wasm or changing screen dimensions circumvents this problem? It's not the fault of the graphics libraries, it may be possible for Macroquad to make it work in these edge cases but I've never looked that deep into it. I just think this is important to mention because using this project is very fitting for low end devices. Here's a link if you like flashing lights in your face: not-fl3/macroquad#520 TLDR: OpenGL drivers are broken on old cards and never got fixed, they mostly work though. For me the intel hd 620 on the current setup works but that could stop working if you add different OpenGL features I think. I believe if you use Vulkan it's supposed to always work on anything that supports it, which is almost everything these days. I'm not saying you shouldn't try an alternative, but it's important to be aware of this. I'd be willing to test it out if you do change crates. Not sure how Also I see your recent commit mentions wasm, so is it supported? |
This is a pretty stale issue, I stopped using |
Oh ok, in that case Edit: @jjant I know you said we should use serve, but what is causing the wasm build to fail on github pages? I ran the bash file then moved files to root. https://github.com/lesleyrs/runty8/tree/wasm-test |
I only mentioned I think yours might have failed because you had too many files in the deployment? I've configured GH pages to use the |
Btw, it's a cool idea to have some games deployed on push to master. Ideally I would like to not need to have these files commited in the repo (i.e, have a GH action run the I'll make a separate issue for this. Edit: See #56. |
Closed as stale/not worth diving into right now. |
You're right after putting the files in a directory it started working, I haven't had that problem before. Also your github pages is pointing to a custom domain that isn't loading: https://github.com/jjant/runty8/deployments |
Description
Rendering is currently implemented using Glium. I picked this library initially because it was the only one I was familiar with.
My main concerns with it are that it looks like WASM is not supported (which we do want), and that compile times may be excessively long for what we need (we only need a handful of OpenGL functions).
Possible alternatives
glow: https://github.com/grovesNL/glow
pixels: https://github.com/parasyte/pixels
It looks like WebGL/wasm support is WIP but it might be ready for the things we need
Raw calls to OpenGL (look into https://crates.io/crates/gl_generator)
The text was updated successfully, but these errors were encountered: